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Volume  I 

Executive  Summery 

SYSTEM  ARCHITECTURAL  CONCEPTS: 

ARMY  BATTLEFIELD  COMMAND  AND  CONTROL  INFORMATION  UTILITY 


1.0  Introduction 


The  Communications  Electronics  Command  (CECOM)  Center  for  System 
Engineering  and  Integration  (CENSEI)  and  the  Jet  Propulsion  Labora¬ 
tory  (JPL)  have  embarked  on  a  program  to  develop  a  distributed 
tactical  command  and  control  system  for  the  Army.  The  following 
material  describes  the  CENSEI  Development  Program  for  Distributed 
Processing  In  general  terms  and  the  role  of  the  JPL  developed 
Command  and  Control  Information  Utility  (CCIU)  in  the  CENSEI  pro¬ 
gram. 

JPL  la  currently  involved  in  developing  the  initial  phases  of  the 
CCIU  portion  of  the  CENSEI  program.  This  document,  the  second  in  a 
series,  presents  early  concepts  and  preliminary  analysis  of  the 
CCIU  system  architecture.  Future  revisions  of  this  document  will 
more  closely  reflect  the  actual  testbed  architecture  and  will 
emphasize  more  pragmatic  than  esoteric  concepts.  It  is  Intended 
that  this  series  of  documents  will  converge  on  a  distributed  archi¬ 
tecture  satisfying  the  guidelines  and  functional  needs  of  the  CCIU. 
The  development  of  this  architecture  will  require  a  simplification, 
condensation  and  coordination  of  the  material  as  presented  in 
Volume  II  of  this  document.  In  addition,  concepts  reflecting  the 
knowledge  gained  from  currently  developed  demonstrations  will  be 
integrated  into  the  architectural  structure.  This  latter 
information  is  Important  in  the  progression  toward  a  realizable 
CCIU  architecture  capable  of  operation  in  a  realistic  military 
environment. 

1.1  pie  CENSEI  Development  Program  for  a  Distributed  Tactical 
Commanl  and  Control  Information  Utility 

1.1.1  Operational  Need 

The  U.  S.  Army  Combined  Arms  Center  (CACDA)  has  Identified  a  set  of 
conceptual  requirements  that  indicate  the  need  for  distributed 
processing  among  the  Army's  battlefield  automated  systems.  The 
basic  requirement  of  the  CCIU  is  to  provide  a  degree  of  surviv¬ 
ability  and  continuity  of  operations  ast intlal  for  execution  of  the 
air/land  battle. 


The  threat  of  the  capability  to  detect  and  determine  the  nature  of 
command  posts  Implies  that  Command  Posts  (CPs)  must  be  geo¬ 
graphically  or  physically  dispersed.  The  purpose  of  this  type  of 


positioning  is  to  deny  the  eneay  the  ability  to  totally  destroy 
essential  coaaand  and  control  functions. 

The  Coaaand  and  Control  of  Subordinate  Systeas  (CCS2)  concept,  as 
articulated  at  Battlefield  Autoaatlon  Appraisal  Five  (BAA  V),  and 
approved  as  the  A  ray  objective  coaaand  and  control  systea,  requires 
the  ability  to  disperse  and  replicate  certain  databases  aaong  key 
operational  facilities  at  each  echelon  of  the  field  Aray.  Further 
certain  functions  aust  be  able  to  be  perforaed  at  facilities  that 
are  designated  as  alternate  or  backup  in  order  to  enhance 
survivability  of  the  entire  coaaand  and  control  network.  The 
specific  functions  will  be  deteralned  by  doctrine  and  organization. 

In  the  role  as  Aray  Coaaand  and  Control  Systea  (ACCS)  Systea 
Engineer,  CENSEI  has  further  characterized  this  set  of  conceptual 
requlreaents  with  four  generalized  distributed  processing  aodels 
(DPMs)  described  in  the  following  paragraphs.  Together  with  the 
CACDA  conceptual  requlreaents,  the  aodels  provide  resources  for  the 
distributed  processing  solution  to  Aray  Coaaand,  Control  and 
Coaaunicatlon  (Aray  C3).  These  coabined  resources  fora  the  basis 
of  the  CENSEI  exploratory  developaent  prograa  in  distributed 
processing;  the  Coaaand  and  Control  Inforaatlon  Utility  (CCIU)  is 
an  integral  part  of  this  prograa. 

The  Distributed  Processing  Models 

The  CENSEI  prograa  for  developaent  of  diatrlbuted  processing 
Includes  both  concept  developaent  and  a  vigorous  prograa  of 
applications  deaonstrations.  For  the  purpose  of  distributed 
processing  concept  developaent,  the  previously  aentioned 
Distributed  Processing  Models  provide  both  a  distributed  processing 
architectural  basis  and  representative  applications  for 
demonstration. 

There  are  four  DPMs:  Cellular  Coaaand  Post,  CCS2  Network,  OPFAC- 
CONOPS  (Operational  Facility— Contlnuity-of-Operations) ,  and  CCIU 
DPM.  They  are  briefly  described  in  the  following  paragraphs.  For 
a  detailed  description,  see  [DIED  81]. 

The  Cellular  Coaaand  Post  DPM 


The  Cellular  Coaaand  Post  (CCP)  is  a  collection  of  Processor 
Eleaents  that  perfora  the  inforaatlon  processing  functions  of  a 
Coaaand  Post.  Each  Processor  Element  is  a  processing  call  capable 
of  executing  software-driven  functions  and  storing  data.  The 
Processor  Eleaents  or  cells  are  Interconnected  by  a  data 
distribution  systea  capable  of  establishing  data  transalsslon  links 
between  all  cells.  For  physical  survivability  the  cells  are 
geographically  separated.  There  are  tb*  ee  foras  of  Cellular 
Coaaand  Post  DPM,  representing  increasing  levels  of  distributive- 
ness.  Involving  the  ability  of  the  systea  to  switch  or  algrate 
functional  capabilities  (both  processes  and  data)  aaong  cells. 


The  CCS 2 DPM 


The  CCS2  jjpjj  implements  the  Training  and  Doctrine  Co  attend  (TRADOC) 
concept  for  partitioning  the  total  Command-Control  system  Into  five 
functional  segments  (Maneuver  Control,  Fire  Support,  Air  Defense, 
INTEL/EW,  and  Combat  Service  Support)  and  employs  a  designated 
Control  Element  in  each  functional  segment.  The  Control  Element 
functionally  coordinates  the  technical  activities  of  Subordinate 
Systems  included  in  the  functional  segment.  The  Control  Element 
also  provides  command/staff  type  information  to  other  Control 
Elements  or  accepts  such  information  from  them.  Processing  cells 
exist  at  each  Control  Element  and  at  the  subordinate  systems  of 
each  Control  Element.  These  cells  are  designed  to  execute  programs 
and  store  data.  They  are  interconnected  by  a  data  distribution 
system  that  can  establish  links  between  designated  cells.  The 
principal  application  of  distributed  processing  is  to  provide  CCS2 
system-level  survivability  in  situations  where  a  Control  Element  is 
lost  or  degraded.  There  are  four  forms  of  CCS2  DPMs  representing 
various  contingency  backup  configurations.  In  these  models  the 
technical  burden  is  on  the  reconfiguration  capability  of  the  data 
distribution  system. 

The  OPF AC-CONOPS  PPM 

The  OPFAC-CONOPS  requirement  in  to  provide  continuity  of  operations 
during  movement  of  a  multi-processor,  multi-shelter  major 
operational  facility.  Bach  shelter  that  contains  a  processor  may 
be  considered  a  cell.  The  system  design  problem  is  to  develop  a 
distributed  processing  approach  that  lets  OPF  AC  perform  its 
functions  adequately  while  some  of  it-s  cells  are  moving 
(displacing).  There  are  three  forms  of  * OPF  AC-CONOP  DPMs  represent¬ 
ing  distribution  levels  of  the  processing  system  control  function. 

The  CCIP  DPM 


The  fourth  DPM  represents  a  system-wide  application  of  distributed 
processing  techniques  to  Army  tactical  Command-Control 
requirements.  Architecturally,  the  CCIU  is  a  collection  of 
computer  hardware,  software,  peripherals,  and  communications.  It  is 
controlled  by  units  in  the  force  structure  and  bound  together  in  a 
loosely-coupled  distributed  resource-sharing  network.  The  workload 
is  shared  among  the  resources  and  is  generally  transparent  to 
battlefield  users.  The  purpose  of  the  CCIU  is  to  provide  survl- 
vable,  secure,  continuously  operable,  adaptable,  high-performance 
capabilities  for  command-control  Information  processing. 

Program  Details 

The  CCIU  work  program  includes  study  efforts  addressing  technical 
alternatives  and  system  design/implementation  details,  laboratory 
simulations,  and  demonstrations  to  evaluate  specific  applications 


of  distributed  processing  approaches*  All  the  DPMs  specified  above 
will  be  addressed  during  the  laboratory  and  field  deaonstratlons. 
For  purposes  of  distributed  processing  concept  development,  the 
CCIU  architecture  will  be  the  basic  data  processing  architecture; 
the  Cellular  Command  Post,  the  CCS2  Network,  and  the  OPFAC-CONOPS 
aodel  are  representative  nodal  applications  of  the  overall  CCIU 
architecture. 

Concept  Development 

The  CENSEI  Concept  Development  concentrates  on: 
o  The  CCIU  development  at  JPL 

o  Analytical  modeling  of  CCS2 

o  Data  compression  techniques  for  Army  C2  information  Transfer 
o  Architectural  concepts  for  Cellular  Command  Posts 
o  Presentation  schemes  for  CCS*  Commander/ Staff  information 


o  Definition  of  minimum  set  of  data  elements 

o  Establishment  of  data  link  protocols  for  distributed 
processing  architecture 

These  major  areas  are  complementary;  together  they  address  numerous 
technical  issues  crucial  to  the  development  of  a  distributed  Army 
command  and  control  system. 

Applications  Demonstrations 


At  four  points  during  the  program  the  emerging  CCIU  distributed 
processing  architecture  will  be  evaluated  using  the  four  DPMs.  The 
first  demonstration,  given  January  1982,  demonstrated  the  rudiments 
of  the  Cellular  Command  Post  in  a  configuration  where  two  Processor 
Elements  each  contained  all  the  functions  and  either  one  served  as 
a  backup  for  the  other.  The  complete  CCP  DPM  and  the  OPFAC-CONOPS 
DPM  will  be  demonstrated  next.  That  demonstration  will  represent  a 
major  step  in  the  direction  of  a  true  distributed  CCIU;  it  will 
Incorporate  most  of  the  control  structures  required  for  all  of  the 
DPMs.  The  third  demonstration  will  be  of  the  CCS^  model,  and  the 
fourth  demonstration  will  be  of  the  CCIU  aodel.  Extensive  hardware 
may  be  required  for  such  a  demonstration  and  it  is  possible  that 
the  test  bed  may  emulate  the  CCIU. 

The  Role  of  CCIU  In  the  CENSEI  Program 


The  CCIU  provides  the  basic  framework  for  the  CENSEI  distributed 
processing  program.  Within  the  CCIU  there  are  three  task  areas: 
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the  System  Architectural  Concepts  Document  (SAC-Doc),  Demonstration 
Development  and  Evaluation,  and  Testbed  Development. 

The  SAC-Doc 


The  SAC-Doc  is  the  repository  for  current  thinking  on  the  CCIU 
system  architecture.  The  document  contains  ideas  directed  toward 
exploring  DPM  design  requirements  and  concentrates  specifically  on 
the  system  design,  and  in  addition,  considers  the  relationship 
between  the  design  and  the  laboratory  demonstrations* 

The  SAC-Doc  is  Intended  to  go  beyond  design  requirements  and  labo¬ 
ratory  demonstrations  because  it  is  not  constrained  by  considera¬ 
tions  of  currently  deployed  capability  or  available  technology.  It 
proposes  potential  problems  and  potential  solutions,  although  not 
every  problem  will  have  a  solution  proposed  in  the  document.  The 
SAC-Doc  will  continue  to  be  updated  throughout  the  year  and 
published  annually. 

The  SAC-Doc  is  also  a  source  of  design  concepts  for  the  various 
CCIU  Laboratory  Demonstrations.  For  example,  the  three-level 
architecture  of  CCIU  described  in  the  June  30,  1981  issue  of  SAC- 
Doc  is  reflected  in  the  design  of  CCP1,  the  first  laboratory  demon¬ 
stration.  CCIU  operating  system  kernel  concepts,  currently  under 
development,  appear  in  this  document  and  will  be  Incorporated  into 
DEM02. 

The  SAC-Doc  also  contains  some  concepts  that  may  never  be  implemen¬ 
ted,  perhaps  because  the  technology  may  not  be  available  in  a 
practical  time  frame,  (for  example,  a  relational  associative  pro¬ 
cessor)  or  perhaps  because  the  concept  may  be  Infeasible  to  imple¬ 
ment  in  the  battlefield  environment.  Fully  decentralized  control, 
with  its  attendant  high  communication  bandwidth  requirements,  might 
be  an  example  of  the  latter.  There  also  may  be  concepts  in  the 
SAC-Doc  that  have  no  direct  operational  requirement  expressed  or 
Implied  by  the  DPMs;  e.g.,  the  use  of  Artificial  Intelligence 
techniques  for  using  data  of  varying  degrees  of  credibility. 

In  summary,  the  SAC-Doc  is  a  current  source  of  specific  and  explo¬ 
ratory  material  on  system  design  concepts  and  architecture.  It  is 
a  major  resource  for  the  specific  purpose  of  building  and  demon¬ 
strating  the  progressive  cspabllities/applications  of  the  CCIU. 

Demonstration  and  Testbed  Development 

Implementation  of  laboratory  demonstrations  is  the  responsibility 
of  the  Demonstration  Development  task.  These  demonstrations  will 
be  Implemented  on  a  testbed  system.  Testbed  hardware  is  currently 
off-the-shelf.  The  testbed  system  design  will  be  compatible  with 
Military  hardware,  specifically  the  TCS  at  the  present  time,  and 
the  Military  Computer  Family  (MCF)  components  as  they  become 


available.  Whan  they  become  'more  widely  available,  Ada  and  its 
software  environment  may  be  similarly  incorporated. 

The  laboratory  demonstrations  will  be  of  the  various  forms  of  the 
DPMs.  However,  the  hardware/ software  configuration  will  be  that  of 
the  testbed,  not  a  fielded  or  soon  to  be  fielded  system.  In  the 
future,  the  necessary  tie  between  laboratory  demonstrations  and 
fielded  or  soon  to  be  fielded  systems  will  be  made  by  Demonstration 
Evaluation  Eeports.  These  reports  will  evaluate  the  potential 
usefulness  of  various  features  of  the  demonstrations  on  the  basis 
of  their  applicability  to  fielded  or  soon  to  be  fielded  systems. 
CENSEI  will  determine  what  further  steps  should  be  taken. 


System  Architecture 

This  section  summarizes  the  CCIU  system  architecture.  The  details 
of  this  material  are  in  Volume  2  of  this  document. 

Objectives 

Four  objectives  of  the  CCIU  design  are  (1)  eventual  use  of  current 
military  hardware,  (2)  attainment  of  a  survlvable  CCIU,  (3) 
security,  and  (4)  provision  for  elements  of  the  CCIU  to  enter  and 
leave  the  network.  These  objectives  result  from  Ref.  [DIED].  An 
additional  objective  resulting  from  good  design  practice  Is 
provision  for  performance  monitoring.  These  objectives  are 
discussed  in  this  section. 

CCIU  Hardware 

The  CCIU  will  be  compatible  with  existing  military  hardware. 
Because  of  limited  availability,  this  hardware  will  not  be  used  for 
the  laboratory  demonstrations  that  are  a  part  of  the  JPL  CCIU 
development  program.  Commercial  hardware  will  be  used  for  these 
demonstrations  but  the  design  will  not  Include  special  hardware 
features  that  do  not  exist  on  military  computers.  The  current 
military  hardware  for  purposes  of  the  CCIU  design  is  the  Tactical 
Computer  System  (TCS).  Although  much  of  the  design  can  be 
transferred  to  the  Tactical  Computer  Terminal  TCT,  the  latter 
equipment  does  not  support  the  hardware  protection  features  used  by 
the  present  CCIU  design  and  considered  essential  to  provide 
reliability  and  security. 

The  performance  of  a  fielded  CCIU  could  be  improved  if  special 
hardware  were  used.  The  SAC-Doc  will  indicate  such  situations  so 
that  CENSEI  can  consider  and  evaluate  the  use  of  special  hardware. 
The  only  example  in  the  current  design  is  considered  in  Section 
2.1.3. 


Survivability  and  System  Integrity 

The  CCIU  must  continue  to  provide  services  to  its  users  after 
destruction  of  some  of  its  communication  links  and  loss  of  some  of 
its .  processor  elements.  Survivability  is  the  term  used  to  identify 
this  characteristic  which  distinguishes  the  CCIU  from  most  computer 
networks.  Survivability  is  attained  by  using  redundant 
communication  links  and  by  replicating  the  user  functions  at 
several  of  the  processor  elements,  termed  backup  elements.  A  more 
complicated  operating  system  requiring  new  design  techniques  Is 
required  to  manage  the  backup  facility.  Survivability  is  also 
affected  by  internal  malfunctions  in  individual  processor  elements; 
these  malfunctions  may  lead  to  total  loss  of  an  element  or  to  its 
continued  operation  in  a  degraded  mode.  Malfunctions  may  arise  from 
hardware  failures  or  from  Incorrect  software. 


The  development  of  fault-tolerant  computing  techniques  Is  currently 
a  very  active  field  of  research.  Paul t-toler ant  computer  hardware 
and  fault-tolerant  software  can  minimize  the  effect  of  failures. 


Fault-tolerant  hardware  provides  additional  redundant  circuit 
elements  in  the  equipment  and  the  hardware  design  masks  errors 
caused  by  circuit  failures.  The  computer  will  operate  correctly 
until  multiple  failures  have  exhausted  the  capacity  of  the  fault- 
masking  capability  to  make  corrections.  Examples  of  techniques  for 
fault  tolerance  are  triple  modular  redundancy,  and  error-correcting 
codes.  Because  of  the  design  restriction  to  existing  military 
hardware  (see  Section  2.1.1)  the  devlopment  of  fault-tolerant 
hardware  is  not  a  part  of  the  CCIU  program.  Current  developments  in 
this  field  are  in  the  direction  of  complete  processing  units  that 
correct  errors;  self-correcting  memories  are  already  available.  A 
fault- tolerant  processor  could  be  used  in  the  CCIU  if  a  technically 
acceptable  one  were  available. 

Fault-tolerant  software  techniques  are  not  as  far  advanced  as 
hardware  techniques.  Often  fault-tolerant  software  techniques  rely 
on  multiple  computation  of  a  partial  result,  sequentially  in  time, 
by  subprogi  using  different  algorithms.  If  comparison  of  the 
results  indicates  an  error,  the  computation  is  automatically 
restarted  at  a  previous  point  where  the  comparison  indicated  no 
error.  The  CCIU  program  is  not  developing  methods  for  writing 
fault-tolerant  software,  but  results  in  the  field  are  being  studied 
and  will  be  incorporated  as  they  become  available.  One  interesting 
development  is  automatic  program  verification  where  the  algorithm 
for  a  computation  is  mathematically  proved  correct.  Such 
technlquaa  are  very  promising;  however,  no  reasonably  sized  program 
has  yet  been  proved  correct  from  the  statement  of  the  algorithm 
down  through  the  production  of  the  computer  instruction  code. 

Hardware  or  software  failure  can  cause  two  very  different 
phenomena.  First,  wrong  answers  can  be  produced;  this  type  of 
failure  is  quite  difficult  to  detect.  A  second  type  of  failure  can 
lead  to  the  program  producing  a  continuous  stream  of  obvious 
nonsense,  not  producing  any  results  at  all,  or  never  terminating. 
In  a  multiprogramming  system  such  as  the  CCIU  where  many  programs 
reside  simultaneously  in  different  parts  of  memory,  a  bad  program 
can  destroy  another  program.  Well-known  techniques,  described  in 
the  next  section,  exist  to  handle  these  second  types  of  failures. 

Security 

CCIU  security  has  two  interrelated  aspects.  The  first  is  security 
in  the  usual  military  sense  of  protecting  the  information  in  the 
CCIU  from  unauthorized  access.  The  second  is  protection  of  the 
system  from  computer  programs  that  are  attempting  an  operation 
outside  their  proper  limits.  Such  programs  may  be  faulty  or  they 
may  be  deliberately  trying  to  compromise  the  system. 


Encryption  can  b«  used  to  protect  Information.  Techniques  for 
encryption  are  outside  the  scope  of  this  program  and  will  not  be 
considered,  but  they  can  be  superimposed  as  desired  on  the 
communication  channels  between  processor  elements  and  on  the  data 
stored  in  the  elements. 

Protecting  the  system  from  malfunctioning  programs  is  accomplished 
by  the  hardware  and  software  mechanisms  briefly  described  below: 

(1)  The  hardware  operates  in  two  modes.  One  of  these  modes  is 
only  used  by  the  operating  system  kernel  (described  in 
Section  2.3.1)  and  contains  privileged  machine 
instructions  that  control  access  to  sensitive  hardware 
mechanisms.  This  special  hardware  feature  is  Included  in 
the  TCS  and  many  commercial  processors.  Examples  of  such 
instructions  are  access  to  the  memory  storage  of  one 
program  by  another,  and  actual  read/ write  operations  on  a 
mass  storage  device. 

(2)  A  capabilities  mechanism  is  provided  in  the  software  to 
allow  cooperating  user  functions  to  share  parts  of  their 
data.  Each  shared  data  object  will  have  a  capability 
associated  with  it.  A  capability  is  a  permit  to  use  that 
object;  the  creator  of  the  object  can  transmit  the 
capability  to  any  other  user  program  that  should  have 
permission  to  access  the  object.  It  must  be  impossible 
to  counterfeit  capabilities.  Software  mechanisms 
enforced  by  the  hardware  privileged  mode  described  in  (I) 
above  can  accomplish  this  result. 

The  capabilities  mechanism  can  also  be  implemented  in  hardware. 
Some  research  computer  hardware  has  been  constructed  in  this  way 
and  a  commercial  implementation  will  be  available  in  the  1APX432 
Microprocessor  under  development  by  the  Intel  Corporation.  This 
type  of  hardware  is  superior  to  software  techniques  for  the 
protection  of  capabilities;  it  should  be  considered  by  CENSEI  for 
possible  use  in  the  CCIU  but  will  not  be  used  in  the  present  design 
because  of  restriction  to  current  military  hardware. 

The  identification  and  authentication  of  individual  users  is 
related  to  data  protection  mechanisms.  Passwords  which  can  be 
encrypted  as  desired  will  be  used  by'  the  CCIU  for  this  purpose. 

2.1.4  Initialization 


The  CCIU  design  provides  well-defined  procedures  for  a  processor 
element  to  come  on-line  and  join  the  network;  the  complementary 
procedure  for  leaving  the  network  also  exists.  Both  of  these 
procedures  are  required  for  the  OPFAC/CONOPS  DPM.  Security  Issues 
are  Involved  in  Initialization  to  prevent  unauthorized  computing 
systems  from  joining  the  CCIU  as  processor  elements.  Survivability 
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Issues  are  involved  because  leaving  Che  network  may  be  involuntary 
and  due  to  communication  link  destruction. 


Performance  Evaluation 


The  CCIU  will  include  software  to  provide  statistics  on  its 
performance.  Such  data  is  essential  to  adjust  system  parameters 
for  optimum  performance.  Gathering  performance  data  incurs 
overhead  in  both  computing  time  and  storage  of  the  date.  In  a 
fielded  CCIU  most  of  this  activity  should  be  automatically 
eliminated  when  the  system  facilities  have  been  reduced  by  loss  of 
processor  elements.  Only  the  data  collection  necessary  for 
continuing  the  reassignment  of  functions  for  backup  should 
continue.  The  current  design  has  not  addressed  the  details  of 
implementing  evaluation  software. 

Overview  of  the  CCIU  System  Structure 

System  Configuration 

Figure  1  is  a  diagram  of  the  physical  structure  of  the  CCIU. 
Computing  facilities,  called  processor  elements,  are  interconnected 
through  a  communication  network.  This  diagram  does  not  restrict  the 
form  of  the  communication  network;  The  current  network  design  is 
described  in  Section  2.2.3*  A  cellular  command  post  cell  will 
consist  of  one  or  more  processor  elements. 

A  typical  processor  element  includes  one  or  more  physical 
processors,  a  memory  storage  device,  and  a  mass  storage  device. 
Computation  is  performed  by  processes;  process  is  defined  as  a 
computer  program  that  accomplishes  pert  or  all  of  a  user  function. 
A  system  process  is  one  where  the  CCIU  is  the  user.  Examples  of 
system  processes  described  later  are  the  contingency  handler  and 
the  resource  manager.  A  processor  element  will  also  have  one  or 
more  terminals  for  individual  users  to  access  the  CCIU  and  possibly 
connections  to  data  sensors.  An  example  of  a  data  sensor  is  radar; 
in  this  case  the  entire  processor  element  might  be  devoted  to 
processing  radar  data.  As  a  part  of  the  CCIU,  the  processor 
element  may  also  perform  backup  functions  for  other  elements.  A 
distinguishing  characteristic  of  the  CCIU  design  is  that  different 
processor  elements  do  not  share  common  memory.  The  communications 
network  is  the  only  interconnection. 

Processor  elements  may  vary  substantially  in  the  resources  they 
contain.  For  exsmple,  an  element  could  contain  a  minimal  processing 
capability  and  be  primarily  a  terminal  multiplexor  through  which 
individual  users  could  gain  access  to  the  CCIU. 


Figure  1.  CCTU  Structure 


Distributed  Operating  Syatea 

The  CCIU  supports  a  distributed  operating  systen  which  manages  the 
entire  network  (see  Figure  2).  The  Processor  Element  Operating 
System  (PEOS)  manages  the  resources  of  a  single  processor  element. 
Superimposed  on  the  PEOS  are  Virtual  Information  Processors  (VIP's) 
that  extend  over  more  than  one  processor  element.  These  are  the 
Command  Slice  Functional  User  (CSFU)  VIP  and  the  Control-VIP.  The 
VIP's  are  implemented  as  processes  on  the  processor  elements. 

The  CSFU-VIP  contains  the  user  processes  that  perform  the  user 
functions  of  a  CCS^  command.  The  designated  individual  users  of 
that  functional  command  interact  with  the  CSFU-VIP  through  the  User 
Input  Directive  Language  (01DL)  described  in  Section  2.4.  A  CSFU- 
VIP  will  normally  reside  in  a  command  post  that  can  encompass 
several  processor  elements. 

The  CSFU-VIP's  use  the  facilities  provided  by  a  Control-VIP.  The 
Control-VIP  will  include  several  processor  elements  within  its 
purview.  Its  purposes  are  to  know  the  processor  element  where 
specific  user  functions  and  system  support  functions  are  located 
and  to  supervise  activation  and  execution  of  functions  in  the 
proper  element.  A  user  function  may  require  the  invocation  of  more 
than  one  process  and  these  processes  may  reside  on  several 
processor  elements. 

The  PEOS  is  described  in  Section  2.3. 

Communication  Network 

The  communication  network  diagrammed  in  Figure  3  has  been  designed 
to  directly  support  the  CCS?  DPM.  This  DPM  calls  for  a  more 
complicated  communication  network  than  either  the  CCP  or  the  OPFAC- 
CONOPS  case.  The  latter  two  DPlTs  are  supported  by  the  communica¬ 
tion  Interface  as  special  cases. 

Four  layers  exist  in  the  configuration: 

(1)  Command  Post  Network  (CPN)  -  This  local  network  connects 
all  the  subordinate  systems  of  a  given  command  post.  In 
the  CCP  DPM  it  is  the  entire  communications  network. 

(2)  Unit  Network  -  This  network  links  together  all  the  CFtTs 
of  a  single  Army  unit  (e.g.,  battalion,  division,  corps). 

(3)  Echelon  Network  -  This  network  connects  the  unit  networks 
at  the  same  echelon  level  (e.g.,  divisions  of  the  same 
corps) . 

(4)  CCIU  Network  -  this  network  links  the  echelon  networks. 
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The  design  is  intended  to  facilitate  local  traffic  and  minimize 
long-haul  traffic.  At  each  level,  the  processor  elements  can  either 
operate  in  a  stand-alone  mode  or  serve  as  gateways  to  interface 
with  another  level.  The  layered  structure  conforms  with  the  Army 
command  structure  so  that  each  subsystem  is  under  the  control  of 
one  commander.  The  layers  are  uniformly  structured. 

The  layered  approach  facilitates  fast  reconfiguration  by  confining 
the  effects  to  one  layer  and  minimizing  propagation  to  higher  or 
lower  layers.  Uniform  design  in  the  Individual  layers  makes  it 
easier  to  reassign  functions  and  reorganize  backups.  CC1U 
configuration  tables  are  also  kept  to  a  manageable  size  by 
confining  their  scope  to  one  layer. 

The  price  paid  for  this  approach  is  increased  overhead  in  network 
operations  requiring  interlayer  traffic.  There  will  be  an  overall 
advantage  if  the  distribution  of  user  functions  can  be  made  so  the 
majority  of  the  traffic  is  local. 

An  important  part  of  the  network  design  is  the  provision  of 
standard  message  types  with  appropriate  protocols  for  common 
message  functions. 

"Processor  Element  Operating  System 

Figure  4  shows  the  operating  system  for  an  individual  processor 
element.  It  contains  three  distinct  entities:  the  kernel,  system 
and  user  processes,  and  system  utility  subroutines.  The  kernel  is 
not  a  process;  it  is  the  basic  part  of  the  operating  system  which 
must  be  initially  loaded  into  the  processor  element  by  an  operator 
and  will  remain  loaded  at  all  times.  It  is  described  in  Section 
2.3.1.  The  system  utility  subroutines  service  all  the  processes  and 
are  centralized  in  one  place  to  save  storage  space.  An  example  of 
such  a  utility  is  a  subroutine  that  would  request  the  opening  of  a 
mass  storage  file  so  the  requesting  process  could  read  it. 

All  CCIU  user  and  system  functions  are  Implemented  by  means  of 
processes.  User  processes  perform  functions  for  the  user  and  will 
not  be  considered  in  this  operating  system  description.  System 
processes  perform  functions  for  the  CCIU;  a  number  of  them  are 
described  in  the  remainder  of  Section  2.3.  System  processes  will 
support  distinct  services  and  will  call  on* each  other  as  required 
to  accomplish  their  work.  Processes  often  need  to  cooperate  with 
one  another  and  thus  must  share  data  and  Interchange  messages. 
These  actions  are  controlled  through  the  capabxlitles  mechanism 
Implemented  in  the  kernel. 


Figure  4.  Processor  Element  Operating  System  (PEOS) 


Kernel 


The  operating  system  kernel  executes  In  the  hardware  privileged 
mode.  It  performs  the  following  functions: 

(1)  context  switching  (shifting  the  processor  from  one 
process  to  another) 

(2)  servicing  the  interrupt-driven  Input/ Output  (I/O)  device 
handlers 

(3)  servicing  interrupt-driven  parts  of  the  communication 
software 

(4)  providing  facilities  for  the  capability-based  software 
protection 

(5)  assigning  physical  resources  such  as  memory  and  mass 
storage 

The  kernel  is  invoked  by  interrupts  and  by  a  set  of  operating 
system  calls  that  can  be  used  by  processes.  Some  calls  require  the 
calling  process  to  have  a  capability  to  make  them.  These  calls 
could  compromise  the  integrity  of  the  PEOS  if  used  improperly. 

Status  Monitor  and  Behavioral  Template 

The  status  monitor  is  a  ystem  process  that  maintains  the  system 
configuration  tables.  It  ..s  a  separate  process  in  order  to  achieve 
modularity  of  the  operating  system  and  is  used  by  all  processes 
needing  configuration  information..  The  status  monitor  is  part  of  a 
Control-VIP;  it  provides  the  VIP  with  information  about  all  the 
VIP's  processor  elements. 

Individual  CCIU  processor  elements  will  have  different 
configurations  and  resources.  The  battlefield  environment  will 
lead  to  fragmentation,  reconstitution,  and  reconfiguration  of  the 
CCIU.  The  configuration  tables  will  be  changing  dynamically.  There 
is  an  initial  configuration  table  for  a  Control-VIP  that  is  called 
the  behavioral  template  and  is  part  of  the  system  data  maintained 
by  the  status  monitor.  It  encompasses: 

(1)  hardware  resources  and  performance  characteristics 

(2)  communication  topology  for  the  processor  elements 
comprising  the  Control-VIP 


(3)  processes  available  at  each  processor  element 

(4)  data  and  its  distribution 

(5)  priorities  of  functions 


(6)  Uses  of  functions  backed-up  at  each  processor  element 
and  backup  locations  for  functions  located  at  the 
processor  element  and  backed  up  elsewhere 

The  Control-VIP  will  attempt  to  maintain  its  configuration  as  close 
to  the  behavioral  template  as  possible. 

2.3.3  Task  Assignment  Manager 

The  Task  Assignment  Manager  (TAM)  locates  a  process  that  has  been 
requested  by  another  process  and  directs  the  Task  Manager  (TM)  to 
make  this  process  active  and  initialize  it.  The  TM  is  described  in 
Section  2.3.4.  The  task  assignment  manager  has  cognizance  of  all 
the  tasks  in  a  given  Control-VIP.  An  example  of  a  requesting 
process  is  the  User  Interface  Directive  Language  (UIDL)  process, 
described  in  Section  2.4,  acting  as  a  result  of  a  user  command 
typed  into  a  terminal. 

Two  ways  are  currently  designated  for  the  TAM  to  locate  a  process. 
The  more  common  is  for  the  TAM  to  consult  the  configuration  tables 
(through  the  status  monitor)  to  locate  the  process.  The  TAM  then 
tells  the  TM  (in  the  appropriate  processor  element)  to  run  the 
process.  The  second  technique  can  be  used  in  case  the  TAM  cannot 
determine  where  the  process  is  located.  In  this  situation  it 
broadcasts  a  message  to  the  processor  elements  asking  if  the 
process  is  available  and  if  current  resources  at  the  location 
permit  the  process  to  be  run.  The  TAM  in  this  way  can  locate  an 
appropriate  processor  element.  A  procedure  called  the  Contract  Net 
Protocol,  described  in  Volume  2,  defines  the  messages  and 
procedures  used  in  the  second  technique. 

The  TAM  is  a  critical  part  of  the  CCIU  and  needs  backup.  If  it  were 
replicated  completely  in  every  processor  element,  excessive  message 
traffic  would  be  Incurred  to  keep  the  TAM  database  of  process 
locations  consistant  in  all  processor  elements  as  the  database 
changes.  The  current  solution  to  this  problem  is  to  have  the  TAM 
code  available  in  all  processor  elements  but  to  have  only  one  TAM 
active  at  a  given  time.  A  method  exists  for  a  new  processor 
element  joining  the  network  to  locate  a  TAM,  and  for  a  new  TAM  to 
be  established  if  the  processor  element  currently  providing  the  TAM 
should  be  lost.  The  Contract  Net  Protocol  can  be  used  in 
emergencies  to  establish  a  new  database  for  the  TAM. 

2.3.4  Task  Manager 

The  TM  is  a  part  of  the  PEOS  in  each  processor  element  that 
initiates  the  running  of  a  process  in  its  particular  processor 
element.  The  TAM  in  a  Control-VIP  will  activate  the  TM  in  the 
appropriate  processor  element  among  those  within  its  control.  The 
TM  accomplishes  its  work  by  calls  to  the  kernel.  After  the  TM  has 
started  a  process,  fiat  process  will  need  to  interact  with  other 
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processes.  The  TM  also  performs  che  function  of  setting  up  channels 
so  messages  can  pass  directly  from  one  process  to  another.  The  TM 
creates  a  capability  for  such  a  message;  a  message  is  a  shared 
object  between  two  processes. 

2.3.5  Resource  Manager 

The  resource  manager  allocates  the  memory,  disk  space,  and  other 
resources  of  a  processor  element  and  contains  the  scheduler  which 
allocates  the  processor  to  active  processes  time-sharing  the 
processor.  Resources  are  allocated  according  to  their  availability 
and  the  priority  of  the  requestor.  Most  resource  assignment  is 
local  to  a  processor  element.  There  is  a  PEOS-resource  manager  to 
assign  these  local  resources.  A  Control-VIP  resource  manager  also 
exists.  Its  purpose  is  to  take  a  global  view  of  resources;  for 
example  it  may  find  it  expedient  to  migrate  a  process  from  one 
processor  element  to  another.  The  resource  manager  uses  other 
operating  system  facilities  to  perform  its  work.  The  physical 
allocation  of  the  resource  is  accomplished  by  a  resource  manager 
call  to  the  kernel. 

2.3.6  CoB&lngency  Handler 

The  contingency  handler  is  a  system  process  that  controls  the 
distribution  of  backup  functions  among  processor  elements.  It 
implements  the  algorithms  that  decide  the  next  step  in  order  to 
ensure  the  survivability  of  the  CCIU  after  another  processor 
element  has  been  lost.  The  initial  distribution  of  backups  is 
determined  by  the  behavioral  template.  A  number  of  circumstances 
affect  the  redistribution  of  backups: 

(1)  the  number  of  currently  existing  backups  for  functions  on 
the  lost  processor  element 

(2)  the  present  computing  load  on  a  proposed  new  backup 

processor  element 

(3)  the  accessibility  of  code  to  implement  the  function  at 
the  proposed  new  processor  element  and  the  ease  with 
which  it  can  be  transferred  if  it  is  not  available 

The  contingency  handler  finds  the  new  backup  processor  elements. 
Other  system  processes  effect  the  decision  depending  upon  the  exact 
circumstances.  For  example,  the  status  monitor  will  always  need  to 
provide  system  information;  the  resource  manager  may  need  to 
transfer  code. 

2.4  Peer  Interface 


The  individual  user  will  Interface  with  the  CCIU  through  a  User 
Input  Directive  Language  (UIDL).  This  language  serves  two 
purposes:  (l)  it  isolates  the  user  from  direct  manipulation  of  the 
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CCIU  processes,  thereby  preventing  modification  of  these  processes 
and  increasing  the  system  integrity,  and  (2)  it  provides  an 
interface  with  user  commands  in  a  vocabulary  familiar  to  the  user. 
A  distinct  UIDL  can  exist  for  each  CSFU  group  in  the  CCIU. 
Provision  will  be  made  for  the  user  to  assemble  a  sequence  of 
commands  and  store  and  recall  them  under  a  name  selected  by  the 
user. 

The  UIDL  will  have  extensive  optional  self-documenting  features  to 
support  minimally  trained  users  as  well  as  a  convenient  shorthand 
for  supporting  expert  users. 

Field  commanders  need  some  degree  of  control  over  the  CCIU 
configuration.  It  must  be  possible  to  add  or  remove  special 
hardware  and  software  required  by  the  current  tactical  situation. 
A  special  group  of  users  called  configuration  controllers  is 
recognized  by  the  system  for  this  purpose.  These  users, 
authenticated  by  special  passwords,  will  be  able  to  adjust  system 
parameters  within  prescribed  limits  and  make  alterations  to  the 
behavioral  template. 

No  provisions  are  made  in  the  CCIU  for  the  field  development  of 
software  at  the  process  level.  The  development  of  groups  of 
commands  for  complex  procedures  as  described  above  is  not  an 
exception  to  this  rule.  Such  procedures  Invoke  a  series  of 
processes  in  sequential  order  but  do  not  create  new  processes. 

Database  Management 

Implementation  of  a  distributed  Database  Management  System  (DMS) 
under  the  survivability  requirements  of  the  CCIU  requires 
substantial  work.  A  design  for  a  DMS  that  will  meet  the  CCIU  DPM 
requirements  has  been  developed.  The  initially  implemented  DMS  for 
the  second  laboratory  demonstration  will  be  reduced  in  scope  from 
this  design;  it  will  implement  the  survivability  rather  than 
distribution  of  data  across  processor  elements.  It  will  be  extended 
to  a  distributed  DMS  for  a  later  demonstration. 


CCIU  operators  do  not  need  to  be  database  specialists  to  operate 
the  DMS.  The  DMS  provides  a  set  of  structures  (views)  to  access 
the  data  by  name.  The  invocation  of  a  given  view  may  lead  to 
complex  operations  on  the  physical  data  to  obtain  the  desired  data. 
The  user  is  expected  to  be  primarily  interested  in  displaying 
various  forms  of  summarized  information.  Two  types  of  transactions 
on  the  database  are  defined:  manipulation  and  perusal.  Perusal 
transactions  will  display  the  data  in  various  ways.  Only  the 
manipulation  transaction  can  modify  the  database.  The  owner  of  the 
data  can  restrict  transactions  and  views  of  his  data  as  he  desires 
by  granting  capabilities  (permissions)  to  users.  Users  will  be 
able  to  combine  the  views  they  have  permission  to  access  into 
derived  views  which  may  further  summarize  the  data  according  to 
their  own  needs.  The  physical  data  organization  will  not  be  visible 


to  the  user  but  will  conform  to  the  relational  model,  i. 
tabular  form. 


Volume  II 

Functional  Description 


1.0  System  Architecture  Overview 
1.1  Background 

The  CC1U  is  a  general  purpose  distributed  Information  processing 
system  designed  to  satisfy  the  Army  tactical  command  and  control 
requirements.  Architecturally,  the  CCIU  consists  of  a  collection  of 
resources  such  as  processors,  storage  modules,  software  modules, 
I/O  devices  and  sensors.  These  resources  are  owned  by  various 
army  units  but  connected  together  in  a  loosely  coupled  network. 
The  network  provides  for  resource  sharing  and  back  up  schemes  to 
ensure  survivability  and  easy  reconfiguration  as  well  as  load 
balancing . 

The  CCIU  will  provide  its  users  with  a  data  processing  facility 
that  performs  a  number  of  well-defined  functions.  These  functions 
will  be  performed  by  a  number  of  processing  elements  Interconnected 
into  a  computer  network.  The  user  need  not  note  this  method  of 
implementation;  it  will  appear  as  though  he  has  a  dedicated 
resource  to  perform  his  functions. 

1*2  Purpose 

The  purpoee  of  this  document  is  to  address  the  major  technical 
Issues  involved  in  the  development  of  the  CCIU,  suggest 
implementation  approaches,  and  identify  functions  and  needed 
resources. 

This  is  a  working  document  in  which  ideas  are  recorded.  Hence,  it 
should  not  be  perceived  as  a  final  and  complete  design  document.  It 
will  be  updated  periodically  as  new  ideas  develop.  At  this  point  no 
distinction  has  been  made  between  ideas  that  can  be  Implemented 
using  existing  technology  and  ideas  that  require  further  research. 

1.3  Architecture  Objectives 

One  of  the  primary  objectives  of  the  architecture  is  survivability 
of  user  functions  in  battlefield  conditions.  vUser  functions  must 
survive  Intact  as  far  as  possible.  In  the  face  of  extreme  loss  of 
physical  equipment,  functions  should  degrade  'gracefully'. 

The  physical  configuration  of  the  system  is  subject  to  arbitrary 
and  dynamic  change.  Communications  links  may  be  cut,  processing 
elements  and  other  equipment  may  be  destroyed  or  removed  as  a 
result  of  battlefield  destruction,  maneuvering  or  maintenance 
(repair).  Similarly  replacement  of  defective  or  destroyed  equipment 
may  later  add  to  the  network. 


There  are  two  extreme  ways  to  achieve  survivability.  In  one,  each 
function  and  database  are  replicated  at  all  processors  and  the 
systea  can  perfora  all  of  its  functions  as  long  as  one  processor 
element  is  fully  operational  (assuaing  coaaunications  links 
intact).  This  has  unacceptably  high  costs  for  the  required 
resources.  At  the  other  extreae,  a  PE  contains  only  its  noraal 
functions.  If  it  fails,  backup  is  possible  only  if  slailar 
functions  exist  at  other  PE's.  Again  this  is  unacceptable.  The 
CCIU  will  atteapt  to  strike  an  optimal  solution  soaewhere  between 
the  two  alternatives  partially  by  replicating  functions  and 
partially  by  aig rating  functions  froa  one  aachlne  to  another  as 
required  for  aaxiaua  survivability. 

In  deterainlng  the  CCIU  architecture  the  following  constraint  needs 
to  be  considered.  The  software  to  perfora  the  functions  will  not 
be  developed  .on  the  operational  systea  and  cannot  be  altered  by  the 
user.  Strict  configuration  control  will  be  aaintained  at  all  tiaes 
with  well-defined  procedures  for  additions  or  alterations  of  the 
software. 

The  architecture  will  realize  a  systea  in  which  each  user  function 
can  be  backed  up  by  replicating  part,  or  all  of  its  programs  and 
data  as  necessary  to  secure  survivability. 

Another  Important  objective  of  the  architecture  is  security.  This 
subject  is  considered  in  aore  detail  in  Section  S  and  in  various 
places  throughout  the  document  as  specific  design  decisions 
implying  effects  on  security  are  presented. 

System  Logical  Structure 

The  CCIU  systea  is  logically  structured  in  three  basic  layers.  The 
top  two  layers,  called  Virtual  Information  Processors  (VIP's),  are 
software  layers  while  the  third  layer  is  the  physical  layer 
consisting  of  the  processor  eleaents.  These  virtual  processors 
are: 

(1)  The  Command  Slice  Functional  User  VIP  (CSFU-VIP) 

(2)  The  Control  VIP  (Control-VIP) . 

The  CSFU-VIP  represents  the  systea  as  it  appears  to  users.  It  is 
the  virtual  aachiine  that  contains  the  programs  that  accomplish  user 
functions  and  its  program  nodules  aay,  as  the  result  of  the  backup 
scheae,  lie  in  different  physical  aachlnes.  The  CSFU-VIP 
lapleaents  the  functional  eleaents  shown  in  the  Cellular  Command 
Post  aodel,  the  CCS^  aodel,  etc.  [DIED  81] ,  but  is  not  aware  of  the 
network  or  the  physical  structure.  The  CSFU-VIP  Interfaces  with  the 
Control-VIP.  This  virtual  aachlne  interfaces  with  the  physical 
layer.  It  is  aware  of  the  network  and  also  knows  the  distribution 
of  the  processes.  Although  it  performs  a  distinct  logical  function 
in  the  network,  it  is  transparent  to  the  user. 


Both  Che  CSFU-VIP  and  Che  Control-VIP  are  pare  of  che  Coacrol 
Element  described  in  che  CCS2  aodel  [DIED  81].  The  CSFU-VIP 
conslsC8  of  che  application  programs  and  che  Conerol-VIP  Is 
realized  by  sofeware  modules  of  che  processor  elemenc  operating 
syscea  (PEOS)  residing  In  a  processor  elemenc.  The  PEOS  manages  a 
network  processor  elemenc  and  incerfaces  wlch  PEOS's  of  PE's  via 
che  Conerol-VIP  services. 

A  Control  VIP  normally  resides  In  one  PE  and  ocher  PE's  use  its 
services  (see  Section  3.3).  However,  che  capability  exists  in  all 
che  other  PE's  Co  execute  this  control  VIP  and  methods  exist  for  an 
orderly  transfer  of  che  control  VIP  function  to  another  PE  should 
ic  become  necessary. 

l.S  Function  Location 


The  user  functions  of  the  CCIU  are  fixed  (Volume  II,  Section  6), 
and  cannot  be  modified  by  the  user.  However,  their  distribution  in 
the  system  may  vary  dynamically  as  the  system  configuration 
changes.  A  dictionary,  maintained  as  part  of  the  configuration 
table  in  the  control  element,  indicates  the  location  of  application 
software  modules  in  processing  PE's.  This  dictionary  is  updated 
and  uaed  by  the  Control-VIP  to  locate  functions  for  the  CSFU-VIP, 
and  in  general  is  transparent  to  tha  user. 

This  dictionary  deacribes  the  distribution  of  functions  in  terms  of 
the  elements  of  the  particular  layer  of  the  network,  in  which  the 
control  element  lies  (see  Section  2.0).  Each  of  these  elements  may 
be  a  network  of  a  lower  layer  containing  its  own  control  element 
with  a  dictionary  describing  further  the  distribution  of  its 
functions  among  its  processing  elements. 

The  dictionary  initially  arises  from  the  behavioral  template  (see 
Section  1.6).  Because  of  the  possible  dynamic  reconfiguration  of 
the  physical  network  it  is  not  possible  to  place  this  table  in  one 
PE  and  always  expect  it  to  be  available.  Therefore,  a  requirement 
exists  for  distributed  knowledge  within  the  system.  Since  it  is  not 
known  a  priori  which  processor  may  fail,  maximum  reliability  could 
be  achieved  only  by  a  complete,  universal  replication  of  the 
dictionary  in  every  PE.  The  provision  for  such  a  complete 
replication  requires  a  communication  and  processing  overhead  to 
keep  all  the  copies  updated.  This  situation  is  analogous  to  the 
previously  mentioned  requirements  for  function  backup.  The  CCIU 
will  attempt  to  obtain  a  cost-effective  solution.  Currently  the 
design  is  based  on  the  idea  that  the  dictionary  is  stored  and 
accessed  in  one  processor  only.  Provisions  are  made  for 
automatically  transferring  the  dictionary  to  another  processor  so 
that  it  will  be  available  if  the  original  processor  fails. 
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1.6 


Initialization 


A  given  CCIU  network  will  be  initialized  with  a  given  set  of 
functions,  processors  and  links  —  not  all  of  which  nay  be 
Initially  available.  This  situation  gives  rise  to  the  concept  of  a 
behavioral  template.  This  is  a  description  of  the  naxlaun 
configuration  of  the  network.  It  includes  a  description  of  the 
placement  of  the  user  functions  in  the  appropriate  processor 
elements.  It  is  the  system  reconfiguration  goal  to  attempt 
realization  of  the  behavioral  template  as  closely  as  possible  in 
terms  of  currently  available  hardware  and  software. 

A  method  must  exist  for  initializing  the  network  and  for  a  PE  to 
either  join  or  leave  the  existing  network.  There  are  security 
issues  involved  in  allowing  a  PE  to  join  the  network;  unauthorized 
processors  must  not  be  able  to  become  part  of  the  network. 

1.7  System  Integrity 

'  System  integrity  includes  characteristics  that  affect  the  availabi¬ 

lity  of  the  system  to  the  user.  Two  aspects  of  availability  are  of 
concern.  The  first  is  the  availability  of  the  system  PE  the  user 
wants  to  use;  the  second  is  the  availability  of  the  system  services 
he  wants  through  any  PE,  especially  if  the  PE  he  would  normally  use 
is  unavailable  [RENN  81]. 

The  system  is  normally  accessible  through  terminals  connected  to  a 
PE.  The  particular  PE  may  be  a  minimal  one  provided  only  to  gain 
access  to  the  network.  In  order  for  the  system  to  be  available  with 
sufficiently  high  probability,  a  number  of  features  must  be 
Included  In.  the  hardware  and  software: 

(1)  The  basic  availability  of  a  given  PE  must  be  maximized. 

(2)  A  backup  capability  must  be  provided  so  that  if  a  PE  should 
fail  or  become  lnacceslble  due  to  communication  failure  the 
services  are  still  provided  to  the  user  through  some  other  PE. 

The  CCIU  will  be  disconnected  from  all  the  users  whose  terminals 
are  physically  connected  to  an  unavailable  PE.  The  reestablishment 
of  service  is  a  logistics  problem  of  gaining  access  to  another 
terminal  connected  to  an  available  PE.  The  problem  from  the  CCIU 
design  standpoint  is  to  ensure  that  the  service  is  available  on 
some  other  PE  and  that  a  terminal,  possibly  connected  to  still  a 
third  PE  can  access  it. 

Backup  can  be  achieved  by  redundant  facilities,  (1)  in  the  form  of 
additional  PE's  placed  in  the  system  only  to  provide  backup  or,  (2) 
in  the  form  of  replicated  data  and  the  processes  for  accessing  it 
deployed  in  existing  PE's  of  the  system.  Replication  of  data 
requires  procedures  for  ensuring  the  consistency  of  the  various 
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copies  should  the  dat  e  needed  without  warning,  e.g.,  due  to 
failure  in  the  prims  y  processor. 

Availability  is  a  term  borrowed  from  the  field  of  fault  tolerant 
computing.  The  hardware  is  designed  to  continue  operation  even 
though  faults  have  occurred  because  fault  masking  is  employed,  or 
the  hardware  detects  faults  and  Institutes  recovery  procedures. 
The  computer  will  continue  to  operate  and  produce  correct  results, 
possibly  with  degraded  speed  or  "throughput"  until  hardware  that 
has  failed  can  be  replaced.  To  accomplish  correct  operation,  the 
computer's  initial  hardware  must  be  augmented  by  additional  redun¬ 
dant  hardware.  The  hardware  must  be  designed  so  it  indicates 
failures  have  occurred.  Maintenance  personnel  can  replace  the 
faulty  hardware  before  the  capability  for  correction  has  been 
exhausted. 

The  CCIIJ  program  is  not  specifically  developing  fault  tolerant 
redundant  processors.  As  previously  mentioned,  this  specialized 
field  is  presently  receiving  great  emphasis  elsewhere.  The  CCIU 
program  is  concentrating  on  the  special  circumstances  that  apply  to 
its  implementation  as  a  network.  The  requirement  for  the  CCIU  as  a 
whole  is  to  continue  to  operate  in  spite  of  the  possible  permanent 
loss  of  some  of  its  processing  facilities  as  well  as  the  temporary 
or  permanent  loss  of  some  of  its  communication  links. 

The  development  of  fault  tolerant  software  is  another  research 
field  of  current  Interest.  In  general,  correct  software  is  written 
by  cycles  of  development  and  testing  eventually  followed  by 
certification. 

A  user  program  should  be  certified  before  use  on  the  CCIU. 
Nevertheless,  it  is  probable  that  some  will  occasionally  fail. 
Recovery  will  probably  consist  of  first  retrying  the  process.  If  it 
continues  to  fail  a  backup  should  be  Implemented.  If  the  failure  is 
due  to  an  uncommon  operation  that  caused  a  bug  to  slip  through  the 
certification  procedure,  the  backup  will  probably  fall,  too.  The 
CCIU  will  generate  an  error  message  but  will  not  stop  the  use  of 
the  program. 

Failure  Recovery 


System  integrity  will  be  considered  in  two  major  categories:  (1) 
communication  network  aspects,  and  (2)  PE  aspects.  These  two 
categories  are  quite  different;  in  both  cases  it  is  software  in  a 
PE  that  undertakes  the  appropriate  action  until  hardware  can  be 
restored  or  replaced. 

A  contingency  handler  process  in  the  PEOS  provides  a  degree  of 
failure  recovery  by  reconfiguring  the  network,  activating  backup 
schemes,  and  redistributing  functions. 
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Recovery  from  loss  of  a  PR  will  consist  of  reassigning  the 
computing  load  to  maximize  the  perforaance  of  the  highest  priority 
tasks  in  the  reaaining  facilities.  Recovery  froa  loss  of  a 
coaaunlcation  link  will  consist  of  finding  another  path  between  the 
affected  PE's,  possibly  an  indirect  path*  In  soae  circumstances 
the  network  aay  becoae  fragaented  into  two  or  aore  networks. 
Reestablishaent  of  a  single  network  when  new  links  are  available  is 
a  coaplicated  problea.  This  fact  results  prlaarily  because  even  in 
a  network  with  totally  decentralised  control  there  is  information 
which  aust  be  global  to  the  network.  The  handling  of  this 
information,  when  the  network  becoaes  disconnected  and  reconnected, 
requires  aerglng  the  split  databases  which  aay  have  becoae 
inconsistent. 

The  basic  fault -masking  techniques  and  reconfiguration  procedures 
should  still  be  applied  to  individual  PR's  to  increase  their 
availability.  It  is  assumed  the  systea  will  be  designed  so  it  can 
contain  fault-tolerant  processors  and  other  hardware.  In  the 
following  discussion,  soae  aspects  of  fault  tolerant  recovery 
procedures  will  be  considered^  We  reiterate  that  correction  of 
faults  can  be  carried  only  so  far  with  a  reasonable  aaount  of 
redundant  hardware.  There  will  always  be  a  Halt  beyond  which  the 
hardware  will  not  work.  Provision  aust  be  made  for  the  orderly 
shutdown  of  a  aachine  to  avoid  daaage  to  databases  and  erroneous 
coaputatlon  if  fault  recovery  has  been  exhausted. 

1.8.1  Coaaunlcation  Failure 


Coaaunlcation  failures  can  take  place  when  a  path  is,  or  is  not  in 
use.  If  the  path  is  in  use,  active  recovery  techniques  are 
necessary  to  ensure  that  processes  currently  communicating  do  not 
slaply  stop  without  indication  because  they  are  waiting  for  a 
aessage  froa  the  other  process.  The  noraal  way  of  detecting  such 
failures  is  through  a  tiaeout  aechanisa  in  the  process  using  the 
channel.  This  is  a  polling  technique  that  not  only  detects  a 
coaaunlcation  failure  but  also  any  problea  in  the  respondent  that 
has  caused  it  to  cease  perforaance.  If  a  problea  is  detected,  the 
OS  aay  be  notified  and  steps  taken  for  recovery.  The  steps  aay 
Include  an  atteapt  to  set  up  an  alternate  channel  to  the  reaote  PR, 
or  an  attempt  to  get  the  data  required  froa  a  completely  different 
source.  The  contingency  handler,  as  well  as  the  task  assignment 
manager,  will  be  involved  in  this  work. 

Oh  the  other  hand  the  failure  of  a  coaaunlcation  channel  not  in  use 
is  not  apparent  until  a  aessage  needs  to  be  sent.  Then  all  the 
aechanisas  for  alternate  routing  or  service  will  have  to  be 
Invoked.  Coaaunlcation  failure  is,  however,  basically  asymmetrical 
with  respect  to  receiving/ sending  messages.  In  order  to  send  a 
aessage,  the  OS  is  active;  it  can  therefore  determine  something  is 
wrong  with  the  channel  and  send  an  error  aessage  to  the  process 
sending  the  aessage.  Using  polling  techniques  to  determine 
channels  are  usable  when  they  are  not  in  use  should  be  considered. 
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This  Increases  Che  overhead  buc  provides  better  system  availability 
for  the  user. 

1.8.2  PE  Failure 


PE  failure  may  require  a  series  of  complex  actions.  Before 
considering  it  we  will  classify  types  of  failures  that  may  occur  by 
the  method  of  detection:  (1)  detection  in  the  PE  itself,  or  (2) 
detection  by  another  PE.  Some  types  of  failure  may  be  found  in 
both  categories  depending  on  the  specific  mechanism. 

A  failure  that  is  not  detectable  by  the  PE  itself  may  result  in  two 
situations.  First  the  network  may  not  be  able  to  communicate  with 
the  PE.  This  situation  may  result  from  a  communications  link 
failure.  Network  protocols  invoking  routing  algorithms  check 
alternative  paths  to  the  PE  automatically.  Thus,  a  communication 
failure  means  all  possible  communications  links  to  the  PE  failed. 
From  the  network  point  of  view  this  is  the  same  as  a  PE  failure. 
The  backup  PE's  should  attempt  to  implement  the  high-priority 
services  provided  by  the  missing  PE. 

A  situation  potentially  more  damaging  to  the  network  could  occur  if 
the  failed  PE  attempts  to  flood  the  communication  channels  with 
spurious  messages  or  garbage.  In  this  case  the  channel  connection 
should  be  shut  off.  If  the  failed  PE  is  large  enough  to  have  a 
separate  communication  front-end  processor,  part  of  the  monitoring 
procedures  in  the  PE  should  be  cross-checking  so  problems  outside 
the  front-end  processor  can  be  signaled. 

If  a  PE  can  detect  internally  that  a  failure  has  occurred,  it  can 
decide  to  recover  based  on  the  redundant  hardware  available,  or 
shut  itself  down  after  notifying  the  netwdrk. 

Specific  examples  of  PE  failures  that  can  be  locally  detected  and 
do  not  incapacitate  the  PE  completely,  include  failure  of  a  user 
program  (or  a  non-crltical  PEGS  module),  and  failure  of  a 
peripheral.  A  peripheral  can  be  a  disk  with  important  data  that 
must  be  obtained  from  other  sources.  In  some  circumstances  it  may 
be  desirable  to  transfer  the  entire  process  using  this  data  to  the 
machine  with  the  backup  data  to  lessen  the  communications  overhead. 
Fbr  example,  a  request  for  summary  information  from  a  database  may 
require  many  queries  but  result  in  little  output. 

The  previous  discussion  considered  fault  detection  from  the  network 
point  of  view.  However  each  PE  will  have  one  or  more  users 
accessing  its  facilities.  The  user  will  presumably  be  able  to 
determine  when  his  PE  is  unavailable.  Well-defined  procedures  for 
the  user  must  be  set  up  to  handle  problem  detection.  In  many 
situations  the  user  will  be  able  to  effect  repairs  and  have  the  PE 
rejoin  the  network. 
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1.9 


Performance  Monitor it 


Two  aspects  of  performance  monitoring  are  important  to  the  CCIU. 
The  first  aspect  is  field  monitoring  carried  out  during  actual 
field  operation  of  a  CCIU.  The  use  of  the  data  collected  in  this 
monitoring  is  considered  in  Section  6.  The  second  is  performance 
monitoring  during  the  development  of  the  CCIU.  Implementation  of 
one  or  more  test  systems  to  experimentally  test  and  verify  design 
concepts  is  necessary.  Monitoring  performance  of  these  test  systems 
is  essential  and  will  be  more  extensive  than  in  the  final  field 
system.  In  a  test  system  the  monitoring  facilities  can  provide 
physical  means  of  simulating  external  environment  effects.  This  use 
of  the  monitoring  facility  would  not  exist  in  a  field  system.  Both 
uses  are  considered  appropriate  for  this  document  and  are  discussed 
in  this  section. 

Monitoring  in  the  field  and  the  test  CCIU  have  two  Important 
functions.  First,  monitoring  enables  the  CCIU  malntalners  to 
decide  how  well  the  CCIU  performs  its  intended  function.  Secondly, 
the  monitor  can  be  used  to  tune  the  system  by  varying  parameters 
and  observing  the  system's  performance.  Examples  are  tiie 
adjustment  of  priorities,  the  distribution  of  common  functions 
among  PE's,  etc.  Additionally,  deficiencies  in  the  design  or 
bottlenecks  in  the  operation  can  be  identified  so  the  system  can 
evolve  into  a  better  one.  An  example  of  this  is  the  identification 
of  significant  communication  delays.  These  delays  might  be 
mitigated  by  additional  links  between  PE's;  this  constitutes  a 
change  in  the  hardware  configuration.  The  delays  may  be  prevented 
by  reassignment  of  function  or  backup;  this  is  an  example  of  the 
adjusting  mentioned  earlier.  A  third  possibility  is  that  delays 
might  indicate  a  defect  in  the  system  logic  that  needs  correction. 

Monitoring  also  has  an  Important  use  in  keeping  an  audit  trail. 
System  use  by  individual  users  can  be  recorded  to  the  extent 
desired  for  later  analysis.  This  use  is  important  from  the 
standpoint  of  security. 

Monitoring  does  require  additional  hardware  and  software  in  the 
CCIU  and  requires  some  expenditure  of  resources  and  processing 
time.  In  a  field  environment,  the  use  of  these  resources  for 
monitoring  may  be  inadmissible  after  some  of  the  PE's  have  failed 
and  the  CCIU  is  operating  in  a  degraded  fashion;  monitoring  is  a 
function  whose  extent  must  be  controlled  by  the  CCIU  contingency 
handling  mechanisms. 

Monitoring  is  a  relatively  low-priority  function  in  a  field 
environment  and  should  be  decreased  or  eliminated  entirely  when  the 
available  facilities  are  decreased.  This  type  of  monitoring 
control  is  uncommon  and  needs  study.  In  the  testbed,  monitoring  is 
a  relatively  high-priority  function;  it  will  tell  where  problems 
occur  when  equipment  and  communication  links  become  unavailable. 
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1.10 


Definitions 
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Definitions  of  Procedures,  Program  Modules  and  Processes  only  are 
provided  in  this  subsection  to  ensure  that  precise  meanings  for 
these  terms  are  specified.  All  other  definitions  appear  with  the 
Glossary  and  Reference  sections. 

1.10.1  Procedures  and  Program  Modules 

A  body  of  code  which  is  already  linked  and  ready  for  execution  will 
be  called  a  procedure.  Note  this  is  not  a  standard  meaning  for  the 
name  procedure*  It  is  roughly  equivalent  to  the  one  in  [ WULF  81]. 

Such  a  procedure  will  normally  reside  on  mass  storage  and  will  be 
replicated  as  required  for  survivability.  When  a  procedure  is  to  be 
run,  the  Task  Manager  (TM)  will  create  a  process  from  the  procedure 
and  run  it.  In  order  to  create  the  process  the  task  manager  may 
need  assistance  from  the  Task  Assignment  Manager  (TAM)  to  locate  a 
processor  where  the  procedure  may  reside.  The  TAM  and  TM  are 
described  in  Section  3.3. 

1.10.2  Processes 


A  process  is  defined  as  an  instance  of  a  procedure  executing  on  a 
machine. 

All  processing  done  in  the  CCIU  will  be  accomplished  by  processes. 
This  includes  not  only  the  user  processes  but  the  operating  system 
processes  with  the  sole  exception  of  the  kernel  of  the  operating 
system.  The  kernel,  which  must  be  in  core  at  all  times  is  not 
realized  as  a  process.  In  order  to  preserve  transparency  of  the 
location  of  processes  we  will  require  tha  processes  only 
communicate  among  themselves  by  messages.  This  method  is  required 
if  the  processes  happen  to  be  in  different  machines  and  will  be 
used  if  they  are  in  the  same  machine.  This  method  specifically 
excludes  shared  memory  as  a  communication  technique;  some 
situations  are  later  noted  where  relaxation  of  this  requirement 
should  be  considered. 

The  operating  system  creates  a  process  by  entering  data  into  tables 
in  the  kernel  nemed  a  "process  control  block".  The  number  of 
concurrent  processes  depends  on  storage  availlbillty.  The  TM  will 
create  and  run  a  process  by  calls  to  the  kernel.  A  possible  kernel 
implementation  is  presented  in  Section  3.2.  A  process  may  be  in 
one  of  the  several  states  noted. 

(1)  Active.  This  is  the  running  process.  Only  one  process  can  be 
active  at  any  given  time  on  a  single  processor. 

(2)  Waiting.  A  process  loaded  into  memory  and  waiting  to  be  run 
when  the  scheduler  calls  for  it.  To  run  it  requires  a  context 
switch. 
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(3)  Blocked.  A  process  is  blocked  when  lc  Is  waiting  for  an  I/O 
operation  to  be  completed.  A  blocked  process  Is  swapped  out  to 
backup  storage  and  the  scheduler  oust  request  the  kernel  to 
load  It. 

(4)  Submitted.  This  is  a  process  that  has  been  created  but  never 
loaded  and  run. 

1.10.3  Task  Force 

Several  processes  may  cooperate  to  perform  a  single  task.  This 
group  of  processes  is  called  a  task  force.  This  concept  is 
particularly  useful  for  a  distributed  task  that  consists  of  several 
processes  on  different  aachines.  A  task  force  may  have  a  central 
‘’executive'*  which  coordinates  its  component  processes,  stores 
coaaon  data,  etc.  but  the  individual  processes  will  coaaunicate 
among  themselves  and  with  the  executive  by  messages  exactly  as  all 
Independent  processes  do.  The  concept  of  a  task  force  is  due  to 
Jones  at  Carnegle-Mellon  Oniv.  [JONE  79]. 

Cooperating  processes  require  some  synchronization  mechanism  to 
permit  one  process  to  invoke  another  as  well  as  communicate  with 
one  that  is  already  running. 
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2.0 


Data  Communications  Network 


2.1  Introduction 

This  section  discusses  network  architectural  concepts  and 
identifies  subsystems  of  the  data  communications  network  for  the 
CCIO  system.  The  network  architecture  addresses  some  of  the 
technical  issues  presented  in  the  CENSEI  document  [DIED  81]  and 
attempts  to  satisfy  the  general  requirements  specified  in  the  four 
distributed  processing  models  (CCP,  CCS^»  0PFAC-C0N0PS,  and  CCIU). 

The  communications  network  provides  the  physical  and  virtual  links 
needed  for  transferring  control,  data  and  voice  message  among  the 
various  subsystems  and  users  of  the  CCIU.  The  network  facilitates 
distribution  of  data  and  processing  functions.  It  also  makes  a 
backup  scheme  possible. 

Some  of  the  basic  architectural  concepts  presented  here  are: 

1.  Layered  architecture  that  conforms  with  the  Army  command 
structure. 

2.  Uniformity  of  control  structure  at  the  various  layers. 

3.  Subsystems  designed  to  operate  in  a  stand-alone  mode. 

4.  Localization  of  control  and  data  traffic. 

Four  basic  layers  have  been  identified.  From  top  to  bottom  they 
are: 

1.  CCIU  network 

2.  Echelon  network 

3.  Unit  network 

4.  Command  Post  Network  (CPN) 

Several  network  control  protocols  have  been  identified.  They 
Include: 

1.  Configuration  protocols  -  Acceptance  protocol.  Exit  protocol 

2.  Status  Monitoring  protocols 

3.  Contingency  Handling  protocols  -  Backup  Activation/ 
Deactivation  protocols  and  reassignment  protocols. 

The  first  part  of  the  section  deals  with  architectural  concepts; 
network  protocols  are  discussed  in  the  second  part. 
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2.2 


General  Network  Architecture 


The  CCIU  network  architecture  is  layered  to  enhance  survivability 
and  nobility.  The  basic  subsystems  of  the  CCIU  are  the  subordinate 
systems  [DIED  81]  connected  by  the  command  post  network.  They 
constitute  the  bottom  layer.  The  subsystems  of  the  higher  layers 
are  configured  in  the  following  manner:  subsystems  of  a  given  layer 
are  linked  together  by  a  network  to  fora  a  subsystem  of  the  next 
higher  layer.  Each  subsystem  contains  a  control  element  that  may  or 
may  not  be  distributed.  The  control  element  provides  management  of 
the  subsystem  network,  and  an  interface  to  a  higher  level  network. 

The  design  philosophy  is  to  build  subsystems  to  support  local 
activities  and  to  minimize  long  haul  control  and  data  traffic. 
Subsystems  at  each  level  are  designed  to  operate  either  in  a  stand¬ 
alone  mode  or  using  the  gateway  capability,  as  part  of  the  higher 
level  network. 

The  layered  structure  is  designed  to  conform  with  the  Army  command 
structure;  each  subsystem  is  under  the  control  of  one  commander. 
Backup  schemes  are  designed  at  each  subsystem  and  between 
subsystems  at  the  same  layer. 

The  layered  approach  facilitates  fast  reconfiguration  by  confining 
reconfiguration  effects  to  the  reconfigured  subsystem  and  minimizes 
their  propagation  to  higher  or  lower  layers.  The  uniform  design  of 
the  various  layers  makes  it  easier  to  reassign  functions  and  re¬ 
organize  backup  schemes.  It  keeps  configuration  tables  at  a 
manageable  size  and  facilitates  mobility  of  subsystems  by  making  it 
easier  to  attach  or  detach  a  subsystem  from  a  higher  layer  network. 
It  alleviates  data  flow  problems  and  shortens  delays  by  providing 
communications  paths  within  the  subsystem  for  local  data  and  con¬ 
trol  traffic. 

The  price  paid  for  this  is  in  terms  of  increased  overhead  for  the 
interlayer  traffic.  However,  since  the  majority  of  the  traffic  is 
local,  the  advantages  outweigh  the  disadvantages. 

The  CCIU  network  is  comprised  of  four  configuration  layers  as 
mentioned  above.  The  first  and  lowest  level  is  the  Subordinate 
System.  It  is  a  cell  of  the  cellular  command  post  and  consists  of 
one  or  more  collocated  processor  elements  (e.g.  in  a  single 
trailer).  The  CPN  is  a  local  area  network  (maximum  distance 
between  elements  1-10  km.)  linking  together  a  set  of  subordinate 
systems  and  a  control  element.  The  control  element  is  also  a  cell 
of  the  CCP  formed  by  processor  elements.  It  controls  the  CPN  and 
provides  the  gateway  capabilities  to  allow  attachment  to  the 
backbone  network.  Each  CPN  may  Implement  a  different  functional 
segment  of  the  CCS^  model  ([DIED  81]). 
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The  Unit  Network  links  together  the  CPN'a  belonging  to  the  saae 
Army  unit  (battalion,  division,  corps).  The  Echelon  Network  links 
together  Unit  Networks  at  the  saae  echelon  level  (e.g.  divisions  of 
the  saae  corps).  Finally  the  CC1U  network  links  the  echelon 
networks  to  a  single  network. 

2.2.1  Configuration 

The  network  is  designed  so  that  each  subsystea  maintains  its  own 
local  configuration  table.  The  configuration  table  records  the 
updated  status  of  each  eleaent  in  the  subsystea,  the  distribution 
and  status  of  the  various  functions  within  the  subsystea,  routing 
information,  and  backup  scheaes,  among  others.  It  is  used  for 
routing  aessages,  resource  allocation  scheaes,  network  initial 
configuration,  reconfiguration  and  more. 

Starting  with  the  Subordinate  Systeas,  the  subsystea  in  the  next 
higher  level  builds  its  local  configuration  tables  based  on  the 
configuration  tables  of  the  lower  level  subsystems  it  links 
together. 

The  CC1U  configuration  tables  maintain  a  dictionary  with  an  entry 
for  each  resource  of  the  Subsystea  in  which  the  updated  status  of 
the  resource  is  kept  (see  Section  1.5).  The  table  Initially  is  the 
saae  as  the  Behavioral  Teaplate  (see  Section  3.4.1).  For  example, 
a  configuration  table  of  a  Subordinate  Systea  has  entries  for  each 
terainal,  I\0  device,  CPU,  auxllllary  storage,  sensors  and  other 
resources  as  well  as  a  list  of  the  available  functions.  A  CPN 
configuration  table  records  the  status  of  each  Subordinate  Systea 
in  the  CPN  and  also  a  list  of  functions  and  their  locations. 

When  a  device  is  added  to  or  taken  froa  the  Subordinate  Systea,  or 
whenever  a  device  changes  its  status  (e.g.  performance  is  degraded 
or  upgraded),  the  Subordinate  Systea  updates  its  configuration 
table  to  reflect  the  changes.  This  change  is  propagated  to  the 
control  eleaent  at  the  CPN  level  only  if  it  affects  the 
functionality  of  the  Subordinate  Systea.  Similarly  a  CPN  updates 
its  configuration  table  whenever  a  Subordinate  Systea  is  added, 
lost  or  recovered  or  whenever  its  status  has  changed. 

2.2.2  Backup  Scheae 

Various  backup  scheaes  could  be  devised  for  the  CCIU  [DIED  81]. 
They  will  not  be  discussed  in  detail  in  this  section.  However,  it 
is  assuaed  that  the  backup  scheaes  will  conform  to  the  layered 
structure. 

Elements  within  a  subsystea  back  up  each  other  as  well  as  the 
control  eleaent  functions.  For  exaaple,  at  the  CPN  level,  subordin¬ 
ate  systeas  within  a  CPN  aay  back  up  each  other  (in  processing 
capability,  storage  capacity  etc.)  and  also  have  the  capability  of 
aanaglng  the  CPN.  Similarly,  at  the  Unit  network  level,  CPN's  aay 
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back  up  each  ocher  (e.g.  by  migrating  processes,  redundant 
distribution  of  functions,  etc*).  At  the  Echelon  level,  Unit  net¬ 
works  back  up  each  other  (e.g.  one  Unit  network  making  a  function 
available  to  a  Unit  network  that  lost  a  similar  function).  Finally, 
at  the  CCIU  level  one  Echelon  network  may  back  up  another  Echelon 
network  at  the  lower  echelon  level. 

Special  network  control  protocols  to  facilitate  backup  schemes  such 
as  Backup  Activation/Deactivation  protocols  will  be  developed.  They 
are  discussed  in  Section  2.4.2.3. 

2.3  Subsystem  Architecture 

The  CCIU  network  contains  two  basic  types  of  networks.  The  CPN  is 
configured  around  a  local  area  network,  and  as  such,  uses  local 
network  techniques  such  as  bus  (or  ring)  structure,  carrier  sense 
multiple  access  or  token  passing  protocols  [CLABt  78].  The  higher 
level  layers  are  configured  as  short,  medium  and  long-haul  backbone 
networks.  The  physical  structure  of  the  networks  will  be 
consistent  with  existing  military  communications.  Bandwldths  will 
therefore  be  limited  to  the  TAC  range. 

2.3.1  Command  Post  Network  (CPN) 

The  Command  Post  Network  (CPN)  is  designed  as  a  stand-alone  system 
that  can  be  attached/detached  to/from  a  Unit  Network  in  a  way  that 
is  transparent  to  the  users.  It  can  function  Independently  from  the 
Unit  Network  but  when  attached  to  the  Unit  Network,  it  serves  as  an 
element  of  this  network  under  control  of  its  control  element,  while 
retaining  autonomy  over  local  functions. 

The  proximity  of  the  elements  of  a  command  post  makes  it  possible 
to  configure  the  Command  Post  Network  as  a  local  area  network.  This 
local  network  serves  several  purposes.  It  serves  as  a  concentrator 
for  the  Unit  Network,  and  provides  for  fast  local  communications 
among  the  users  in  the  command  post.  It  links  together  several 
subordinate  systems  and  various  terminals,  sensors  and  possibly 
mass  storage  devices  shared  by  them,  and  a  network  control 
element  that  provides  local  network  control  and  a  gateway  to  the 
Unit  Network. 

The  logical  structure  of  CPN  is  a  bus  structure,  (broadcasting 
network).  This  allows  for  easy  reconfiguration  and  facilitates  the 
backup  scheme. 

2.3.2  Backbone  Network 


The  backbone  network  comprises  the  three  higher  layers  of  the  CCIU 
network:  the  Unit  Network  linking  together  the  CPN's  of  a  single 
Army  unit  (e.g.  battalion,  division,  corps),  the  Echelon  network 
tying  together  the  the  Unit  Networks  of  all  the  units  in  the  same 
echelon  (e.g.  all  the  divisions  of  the  same  corps),  and  the  CCIU 
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network  chat  connects  the  echelon  networks  Into  a  single  network. 

Networks  at  each  layer  should  be  able  to  function  Independently  of 
the  other  networks  at  the  same  or  higher  levels.  To  facilitate  the 
stand-alone  capability  and  the  interface  to  the  higher  layer,  each 
network  has  a  control  element  that  may  be  either  centralized  or 
distributed. 

To  enhance  survivability,  the  control  elements  at  each  level  should 
be  upward  compatible  so  they  can  back  up  control  elements  at  the 
seme,  lower,  or  higher  levels. 

Communication  medium  used  by  the  backbone  network  is  likely  to  be  a 
combination  of  radio,  satellite  communications,  and  terrestrial 
networks  (The  TRI-TAC  army  network,  public  network,  telephone 
lines).  The  selection  of  a  particular  medium  depends  on  the 
mobility  of  the  units,  physical  environment,  and  other 
considerations. 

2.4  Protocols 


Protocols  are  needed  to  create  the  virtual  communications  medium 
with  certain  desirable  characteristics  that  are  more  useful  than 
the  "naked"  physical  links.  They  provide  services  such  as  message 
sequencing,  priorities,  error  and  flow  control.  They  also  estab¬ 
lish  standard  data  elements  and  communications  conventions  [MCQU 
78,  TANK  81]. 

The  protocols  of  the  CCIU  serve  two  basic  purposes.  Data 
transmission  protocols  serve  the  CSFU-VIP  and  the  Control-VIP  by 
facilitating  the  transmission  of  data  and  control  messages  among 
the  subeystems  of  the  CCIU.  The  network  control  protocols  serve  the 
Control-VIP  in  resource  allocation,  status  monitoring, 
configuration  and  reconfiguration  of  the  network. 

Protocols  provide  for  standard  information  exchange  messages 
between  processes,  and  are  a  part  of  the  communications 
architecture.  The  Control-VIP  protocols  discussed  here  are  closely 
related  to  the  system  processes  used  by  the  PROS  and  described  in 
Section  3.  References  are  given  tj  the  appropriate  section  in  the 
subsequent  descriptions. 

2.4.1  Data  Transmission  Protocols 


In  general,  it  is  advisable  that  the  CCIU  data  transmission 
protocols  will  be  compatible  with  the  1S(M)SI  reference  model  [ZIMM 
80],  which  is  becoming  the  standard  for  the  civilian  networks. 
This  will  enable  CCIU  to  take  advantage  of  existing  public  networks 
when  possible. 
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It  Is  quits  conceivable  that  requirements  on  the  CCIU  will 
necessitate  modifications  from  the  ISO-OS I  reference  model  in  order 
to  enhance  security  measures  and  reduce  overhead. 

2.4.2  Network.  Control  Protocols 

The  network  control  protocols  are  subdivided  into  three  categories: 
configuration  protocols,  status  monitoring  protocols,  and 
contingency  handling  protocols. 


2.4. 2.1 


Configuration  Protocols 


These  protocols  help  in  configuring  the  network.  They  facilitate  an 
orderly  attachment/detachment  of  CCIU  subsystems  (e.g.  a  CPU) 
to/ from  the  network.  Two  protocols  have  been  identified:  the 
Acceptance  Protocol  used  during  an  attachment  and  the  Exit  Protocol 
used  when  the  subsystem  is  detached. 


2. 4. 2. 1.1  Acceptance  Protocol 


When  a  subsystem  is  attached  to  e  higher  level  network  (e.g.  a  CPU 
to  the  Unit  Network),  the  Acceptance  Protocol  is  carried  out 
between  the  network's  operating  system  and  its  counterpart  in  the 
subsystem  being  attached.  Messages  are  exchanged  to  make  the 
subsystem  "known”  to  the  network  and  vice  versa.  The  content  of  the 
messages  is  used  to  update  the  appropriate  configuration  tables. 
They  convey  Information  about  functional  distribution,  processing 
end  storage  capabilities  and  more.  This  protocol  also  allows  for 
security  checks  and  authentication  procedures. 


2.4.2. 1.2  Exit  Protocol 

When  a  subsystem  is  detached  from  the  higher  level  network,  the 
Exit  Protocol  is  utilized.  This  is  done  in  order  to  update  the 
configuration  tables  and  activate  backup  procedures  to  replace  the 
lost  resources  (e*g.  migrate  processes,  reassign  functions,  etc.). 

Exit  protocol  is  also  used  when  a  subsystem  sustains  such  a 
considerable  loss  that  it  cannot  totally  recover  by  Itself,  or  when 
it  is  going  down  but  has  sufficient  time  to  go  through  the 
.  protocol. 


2. 4. 2. 2  Status  Monitoring  Protocols 


Status  protocols  monitor  the  status  of  the  various  subsystems  and 
communication  links.  This  monitoring  activity  is  necessary  so  the 
network  keeps  track  of  loss  or  rscovery  of  functions,  resources, 
sad  communication  links.  Examples  of  algorithms  that  can  be  used 
for  this  purpose  ere  the  echo  elgorithms  [CHAN  79].  Status 
Monitoring  is  considered  in  Section  3.4. 
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Two  basic  approaches  to  monitoring  are  mentioned  briefly.  One 
approach  is  status  reporting  where  subsystems  send  their  status 
update  report  periodically  to  the  control  element.  The  other 
approach  is  status  inquiry,  where  status  update  inquiries  are 
issued  periodically  to  each  of  the  subsystems  by  the  control 
element.  Yet  another  approach  is  the  use  of  the  combination  status 
reporting  and  inquiry. 

Whenever  a  major  loss  is  detected  as  a  result  of  status  monitoring 
a  contingency  handler  routine  is  invoked. 

2. 4. 2. 3  Contingency  Handling  Protocols 

These  protocols  are  used  whenever  reconfiguration  is  needed  as  a 
result  of  orderly  detachment  of  units  or  as  result  of  a  temporary 
or  permanent  loss  of  resources  or  communication  links.  To  reconfig¬ 
ure  the  system  the  contingency  handler  (see  Section  3.6)  needs  to 
activate  backup  resources.  For  this  purpose  the  Backup  Activating 
Protocol  is  used  between  the  control  element  and  the  backup  sub¬ 
systems.  If  the  loss  is  temporary  (e.g.  for  repair),  when  the 
resource  is  up  again  the  backup  resource  needs  to  be  deactivated. 
This  calls  for  another  protocol,  the  Backup  Deactivating  Protocol. 

The  CCIU,  at  all  levels,  may  need  to  reassign  functions  as  well  as 
reorganize  backup  schemes  resulting  from  heavy  losses.  This  task 
conceivably  requires  quite  complex  communications  among  the  various 
operating  systems.  A  set  of  protocols  will  be  needed  for  this 
purpose.  They  are  referred  to  collectively  as  the  Reassignment 
Protocols.  The  contract  net  protocols  are  examples  of  such 
protocols  [SMIT  79]. 

2.5  CCIU  Architecture  vs.  Data  Processing  Models 

The  CCIU  network  architecture  discussed  here  supports  the  Data 
Processing  Models  (DPM's)  described  in  the  CENSEI  Exploratory 
Development  Program  [DIED  81]. 

The  Cellular  Command  Post  (CCP)  can  be  realized  by  a  single  CPN. 

Each  of  the  functional  segments  of  the  CCS2  model  can  be  realized 
by  a  specialized  CPU.  The  various  layers  of  the  backbone  network 
correspond  to  the  echelon  and  interechelon  communications. 

The  OPFAC-CONOPS  model  is  supported  by  the  stand-alone  and  gateway 
capabilities  of  the  subsystems  and  the  conformity  of  the 
architecture  to  the  command  structure. 

The  layered  structure  supports  the  general  objectives  of  the  CCIU. 
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3.0 


Architecture  Of  The  Processing  Element  Operating  System 
3.1  Introduction 


In  Section  (1)  an  overall  view  of  the  network  operating  system  was 
given.  The  network  was  described  as  a  hierarchical  structure  of 
virtual  processors:  the  Coaaand  Slice  Functional  User  (CSFU-VIP) 
and  the  Control-VIP  built  on  Processor  Eleaents  (PE's).  This 
section  describes  in  detail  the  operating  system  that  exists  in 
each  of  these  PEs. 

Figure  1  shows  an  overview  of  the  PEOS.  It  is  coaprised  of  three 
layers:  user,  supervisor,  and  kernel.  The  PEOS  includes  software 
aodules  that  control  the  local  operations  of  the  processing  eleaent 
and  also  contains  aodules  of  the  distributed  network  operating 
systea  that  provide  access  to .  reaote  resources. 

The  kernel  is  at  the  lowest  level  of  the  PEOS.  It  contains  a  set  of 
operations  that  are  called  by  a  well-defined  set  of  prlaltlve 
coaaands.  These  calls  are  used  by  the  kernel  In  order  to  perfora 
the  prlaary  functions  of  aanaglng  the  processor,  the  primary  memory 
and  the  controllers  for  peripheral  devices.  Section  (3.2)  outlines 
a  possible  Implementation  of  the  kernel. 

With  the  exception  of  the  kernel,  all  processing  on  the  machine  is 
done  by  processes  defined  in  Section  (1.10.2).  In  order  to 
accomplish  their  work  processes  call  on  the  primitive  operations  of 
the  kernel  and  communicate  with  other  processes  to  exchange 
information.  Processes  on  a  given  PE  may  share  reentrant  coaaon 
utility  subroutines.  The  CCIU  accoaplishes  all  communication 
between  processes,  either  local  or  reaote,  by  means  of  messages  (as 
opposed  to  shared  aeaory).  Using  messages  for  local  interprocess 
communication  causes  additional  overhead.  However,  a  unified 
communication  method  for  all  processes  makes  interprocess 
communications  independent  of  the  location  of  the  communicating 
processes  and  the  migration  of  processes  from  one  PE  to  another  (to 
accomplish  backup)  is  facilitated.  To  communicate  with  a  remote 
process  the  PEOS  uses  its  network  interface  module. 

The  two  outer  layers  of  the  PEOS,  the  supervisor  and  the  user 
layer,  contain  nothing  but  processes.  The  kernel  operates  in  the 
hardware  privileged  mode. 

Processes  run  concurrently  sharing  memory,  I/O  devices,  CPU's,  and 
other  resources,  it  is  necessary,  therefore,  to  protect  them  from 
injury  by  a  malfunctioning  process.  It  also  necessary  to  schedule 
resources.  All  this  is  accomplished  by  the  kernel  (running  in  the 
privileged  mode)  by  restricting  process  access  to  resources  such  as 
the  memory,  processor  time,  and  by  controlling  communication  to 
other  processes.  In  the  CCIU,  a  capability  mechanism  has  been 
chosen  for  controlling  process  access  to  anything  it  does  not  own. 
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Figure  1.  Processor  Element  Operating  System  (PEOS) 


In  che  supervisor  layer  there  are  a  number  of  processes  identified 
as  being  peculiar  to  the  CCIU  system.  These  are:  (1)  the  task 
assignment  manager,  and  task  manager  that  controls  locating, 
location  and  activation  of  tasks,  (2)  the  resource  manager  that 
controls  assignment  of  PE  resources  and  may  attempt  to  off-load 
processes  onto  another  PE  if  that  is  desirable,  (3)  the  contingency 
handler  that  attempts  to  redistribute  backup  functions  within  the 
system  as  necessary  to  handle  problems  arising  from  failed  PE's  and 
communication  links,  and  (4)  the  system  status  monitor  that 
contains  information  regarding  system  configuration  status  and  CCIU 
performance.  Mote  all  of  these  processes  require  some  knowledge  of 
other  system  PE's  and  lie  within  a  Control-VIP. 

The  user  layer  contains  processes  that  are  accessed  by  the  user  or 
are  common  sub-processes  used  by  the  primary  user  processes.  Due 
to  the  well-defined  nature  of  CCIU  functions,  these  user  processes 
will  be  command  interpreters  that  accept  user  commands  and  execute 
appropriate  functions. 

3.2  PEPS  Kernel 

The  PE  OS  kernel  will  be  the  only  part  of  the  PEOS  that  operates  in 
the  hardware-priviledged  mode  and  has  access,  to  all  privileged 
instructions.  It  contains  the  capability  mechanisms.  All  other 
software  will  operate  in  the  unprivileged  mode.  Not  all  of  the 
"trusted  code"  is  in  the  kernel.  The  trusted  code  outside  of  the 
kernel  is  able  to  perform  its  function  by  accessing  restricted 
objects  through  its  capabilities;  access  is  mediated .by  the  kernel. 

The  kernel  operates  the  machine  hardware,  l.e.,  the  processor,  the 
memory  and  the  peripheral  devices.  The  kernel  provides  entry 
points  for  user  and  system  software  to  access  functions  it 
provides.  These  entry  points  permit  the  kernel  to  manage  the 
software  objects  it  provides  to  other  software  modules.  Basic 
types  of  objects  supported  by  the  kernel  are: 

1.  Processes 

2.  Memory  blocks 

3.  Devices 

4.  Capabilities 

5.  Messages 

These  software  objects  are  described  next. 

3.2.1  Processes 

A  process  was  defined  in  Section  1.10.2.  A  function  of  the  kernel 
is  to  manage  the  allocation  of  the  processor  and  other  resources  to 
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che  processes  competing  for  chelr  use.  As  a  message-handling- 
facility  the  CC1U  requires  that  large  numbers  of  processes  be 
created,  used  and  destroyed.  The  process  management  facilities 
must  be  able  to  do  this  without  incurring  a  large  overhead. 

Primitives  required  for  process  management  are:  (1)  create  process, 

(2)  destroy  process,  (3)  initialize  process,  (4)  run  process,  and 
(5)  return  from  process.  These  primitives  are  described  below. 

(1)  Create  process  -  constructs  a  new  process  out  of  a  program 
module  (more  then  one  concurrent  process  may  be  created  from 
the  same  module).  Invoking  this  primitive  causes  a  Process- 
Control-Block  (PCB)  to  be  created  with  suitable  entries  that 
identify  the  process  to  the  system  and  add  this  PCB  to  the 
appropriate  queue. 

(2)  Destroy  process  -  removes  all  knowledge  of  the  process  from 
the  system  tables. 

(3)  Initialize  process  -  obtains  initial  memory  space  for  the 
process  and  provides  initial  information  for  it.  Initial 
information  may  consists  of  initial  values  for  some  variables 
and  messages  from  the  calling  process.  The  initial  memory  for 
a  process  consists  of  space  for  its  variables  and  stack  space. 
See,  e.g.  the  Local  Name  Space  (LNS)  in  [WOLF  81]  and  see 
[MYER  80  J. 

(4)  Run  process  -  passes  control  of  the  processor  to  the  process. 
It  is  normally  invoked  by  a  scheduler. 

(5)  Return  -  blocks  a  process  from  further  using  the  processor.  A 
process  can  use  this  primitive  to  relinquish  control  of  the 
processor  back  to  the  PROS.  Ordinarily,  the  PEOS  will  regain 
control  of  the  processor  as  a  result  of  other  circumstances. 
Either  an  interrupt  will  occur  or  the  running  process  will 
make  a  service  call  to  the  PEOS  that  will  result  in  the  OS 
using  the  processor  to  process  the  service  call.  The  OS  can 
make  a  scheduling  decision  regarding  the  next  process  to  run. 

The  two  primitives  "run"  and  "return"  are  intimately  concerned  with 
scheduling  the  processor  resource.  Normally  the  PEOS  will  assign  a 
priority  to  a  process  from  information  provided  by  the  process 
initiator.  A' time  allotment  based  on  the  process  priority  will  be 
assigned  and  used  for  sharing  the  processor  among  processes.  Time 
given  the  process  each  time  it  runs  depends  on  both  time  allotment 
and  machine  load.  Processes  will  continue  to  run  until  their  time 
allotment  is  used  or  they  stop  for  a  reason  outlined  above.  The 
kernel  decides  which  process  to  run  next.  Note:  waiting  processes 
of  higher  priority  than  the  process  currently  running  can  obtain 
the  processor  at  any  time  interrupt  point.  It  is  planned  that 
process  priority  assignment  be  handled  outside  the  kernel  by  some 
scheduling  process.  Management  of  the  ready  process  queue  is  so 
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closely  cled  with  kernel  functions  such  as  processor  assignment, 
memory  swapping,  interrupt  handling,  etc.,  it  should  be  in  the 
kernel  itself. 

The  kernel  provides  access  to  information  about  processes  on 
request  to  a  process  with  proper  capabilities.  As  an  example,  the 
priority  scheduler  needs  to  know  how  much  accumulated  processor 
time  a  given  process  has  used  to  determine  changes  in  the  priority 
of  the  process  so  that  an  absolute  time  limit  to  accomplish  the 
work  is  met. 

3.2.2  Memory  Blocks 

The  kernel  must  have  the  ability  to  assign  memory  space  to 
processes  both  for  their  exclusive  use  and  for  controlled-sharlng 
with  other  processes  in  the  same  processing  element.  Memory  is 
organized  hierarchically  in  two  levels:  main  storage  fast  memory 
and  secondary  storage  on  disk  or  other  media.  The  PEOS  includes  a 
virtual  memory  manager  that  implements  the  paging  system. 

3.2.3  Devices 


The  kernel  controls  I/O  operations  and  physical  I/O  devices.  I/O 
device  control  primitives  are  (1)  start  I/O,  (2)  I/O  completion. 
Invoking  the  I/O  Interrupt  handler  is  not  a  kernel  primitive 
because  it  is  initiated  by  the  hardware  itself. 

3.2.4  Capabilities 

The  general  consensus  is  that  the  provision  of  security  in  an  OS 
must  be  part  of  the  basic  design  and  not  something  added  to  an 
existing  system.  The  latter  technique  has  been  used  many  times  and 
has  always  led  to  systems  that  were  easily  penetrated.  The 
security  technique  currently  considered  the  most  promising  is  the 
capabilities  technique.  For  more  on  the  subject  of  operating  system 
security  in  general  see  [HSIA  78].  Capabllitles-addresslng  of 
system  objects  is  used  in  several  current  research  OS's:  [POPE  79; 
WARD  80;  MCCR  80;  BEAT  80;  SINC  80].  The  Inverse  of  capabilities, 
the  access  list,  is  used  in  the  M0LTICS  system  at  M.I.T.  Mote: 
capabllitles-addresslng  has  other  advantages  in  an  OS  [FABR  74]. 
Capabilities  can  be  implemented  by  means  of  software  or  by  direct 
hardware  decoding  of  the  capability.  The  latter  is  a  more  secure 
technique  but  requires  a  special  processor  memory  unit.  Such  a 
hardware  technique  has  been  used  in  the  IBM  SWARD  machine  [MYER 
80] ,  in  the  IBM  System  38  [BERS  80] ,  and  in  the  INTEL  432  system. 
We  will  assume  that  the  software-based  technique  using  ordinary 
hardVare  is  being  implemented  in  the  CCIU. 

Our  model  provides  that  every  process  is  given  some  private  memory 
accessible  only  to  it;  the  memory  is  protected  by  the  memory 
management  system  address  access  limits.  Any  sharable  object  and 
any  message  object  is  created  and  given  a  name  by  the  operating 


43 


3.2.5 


system  on  request.  Sharablility  of  memory  blocks  should  be 
considered;  this  can  significantly  decrease  the  process 
communication  overhead.  The  block  would  be  created  by  agreement 
between  the  processes  obtained  through  messsge  passing. 

There  are  three  primitives  required  In  the  kernel  for  capability 
management:  create,  grant,  and  revoke.  In  addition  to  these 
primitives  the  kernel  must  also  use  Its  knowledge  of  process 
capabilities  to  control  access  to  objects  when  other  kernel 
primitives  are  used  by  the  various  processes.  In  the  UCLA  secure 
UNIX  kernel  [POPE  79]  the  capability  information  storage  is  inside 
the  kernel.  Other  systems  do  not  do  this;  it  tends  to  make  the 
kernel  large  thus  consuming  a  large  amount  of  fast  memory  storage. 
A  middle  ground  technique  would  be  to  provide  secondary  storage 
accessible  only  to  the  kernel.  This  can  be  done  if  the  kernel 
implements  a  simple,  paged  file  system  with  its  own  capability 
control,  and  the  user-accessible  file  system  is  a  process  using  the 
basic  pages.  This  is  the  file  system  proposed  in  previous 
paragraphs.  Such  a  file  system  (but  without  capabilities  in 
secondary  storage)  has  been  used  in  [POPE  79]  and  in  the  XEROX  WPS 
system  on  the  experimental  Ethernet. 

A  capability  code  should  not  be  reused  for  a  new  object  after  the 
original  object  has  been  deleted.  This  leads  to  very  long 
capability  strings  in  the  mechanization  (e.g.,  82  bits  in  the  SWARD 
system,  [MYER  80]);  it  may  be  desirable  to  investigate  a  technique 
for  relaxation  of  this  requirement. 

It  is  necessary  distinguish  among  various  types  of  access  rights  in 
the  capability.  Different  access  controls  must  exist  for  reading 
from,  writing  into,  using,  and  deleting  objects.  In  addition,  there 
should  be  a  set  of  rights  granting  permission  for  altering 
capabilities  as  they  are  passed  to  other  processes.  Such  alteration 
may  consist  of  restricting  the  rights.  In  [WULF  81]  the  necessity 
for  amplifying  rights  in  some  situations  is  considered. 


The  message  handler  will  be  a  trusted  process  outside  the  kernel. 
The  kernel  will  be  involved  in  message  handling  because  (1)  a 
capability  will  be  involved  for  sending  the  message  and  (2)  the 
actual  link  level  of  communication  will  involve  interrupt-  driven 
hardware.  Messages  may  also  serve  as  a  synchronization  means 
between  processes.  [RAO  80]  discusses  message  handling  procedures. 

Messages  are  a  different  category  of  object  fiom  other  objects. 
Other  objects  handled  by  the  kernel  exist  inside  the  PE  and  the 
kernel  would  immediately  know  what  resources  are  available  when  a 
request  is  made.  Messages  go  to  another  process  that  may  be  in 
another  PE;  there  is  no  guarantee  the  other  process  is  going  to 
read  the  message  within  any  given  time.  Therefore,  the  message 
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resource  is  not  under  kernel  control  and  the  strategy  for  handling 
all  cases  is  difficult  to  determine. 

Messages  can  be  used  to  set  up  a  direct  channel  between  two 
processes  for  the  exchange  of  data.  See  [WARD  80]  where  such 
channels  are  called  streaas  and  treated  as  a  generalization  of  the 
UNIX  pipe  facility.  This  facility  will  be  implemented  outside  the 
kernel.  The  kernel  will  be  involved  in  creating  and  checking  the 
capabilities  required. 

The  strategy  for  message  handling  should  attempt  to  avoid 
deadlocks.  Deadlock  avoidance  has  been  shown  to  be  an  MP-complete 
problem;  one  solution  that  has  been  implemented  is  to  detect  dead'-’ 
locks  and  resolve  them.  There  are  two  common  message  strategies: 
(1)  the  sending  process  blocks  after  sending  a  message  until  it 
receives  a  reply,  or  (2)  it  continues  immediately  and  tests  later 
to  see  if  the  message  was  received  by  the  receiving  process.  Both 
of  these  strategies  can  easily  lead  to  deadlocks.  The  no-wait 
strategy  will  fail  if  the  buffer  storage  resource  is  used  up  and  no 
more  messages  can  be  queued.  This  can  happen  if  a  process  does  not 
read  its  Incoming  messages.  The  wait  strategy  will  fail  if  two 
processes  happen  to  send  messages  to  each  other  simultaneously  and 
neither  can  proceed  until  the  other  has  responded. 

Another  consideration  for  synchronization  is  the  action  to  be  taken 
by  a  receiving  process  when  it  wants  to  read  a  message.  It  may 
continue  Immediately  with  other  work  and  check  occasionally.,  or  it 
may  block  until  the  message  is  received.  A  receiver  process  that 
is  listening  for  messages  from  anyone  and  attempting  to  do  some 
other  work  simultaneously  needs  the  former  strategy.  A  process  of 
this  type  is  exemplified  by  the  'listening'  socket  on  the  Arpanet 
that  sets  up  the  secondary  channels  used  when  two  hosts 
communicate. 

The  basic  primitives  for  message  passing  are  send  message  and 
receive  message.  Blocking  or  non-blocking  options  are  essential  to 
provide  for  fault  tolerance  and  synchronization.  They  can  be  part 
of  the  arguments  to  the  call.  The  basic  kernel  primitives  will 
normally  be  issued  only  by  the  message  handling  process  and  not  by 
any  user  process  directly. 

Sending  a  message  requires  an  address.  The  address  can  be  the  name 
of  a  process  or  it  can  be  the  name  of  an  entity  established  for 
messages  that  communicate  with  tt  process.  The  latter  technique 
is  commonly  known  as  a  "port”.  If  there  are  large  numbers  of 
temporary  processes  in  existence,  it  could  be  difficult  for  a 
sending  process  to  know  the  name  of  the  process  it  wishes  to 
communicate  with.  This  difficulty  is  overcome  by  the  port  that  is  a 
standard  receive  point  for  the  classes  of  messages  it  redistri¬ 
butes.  If  this  technique  is  used  in  the  CCIU  the  port  is  usurping 
one  of  the  prerogatives  of  the  TAM  which  knows  the  location  of  all 
processes;  therefore,  the  technique  has  not  been  adopted. 


Additional  Kernel  Functions 


The  kernel  has  some  functions  that  do  not  fit  into  the  category  of 
system  object  handling*  These  functions  follow: 

The  kernel  will  be  responsible  for  the  initial  actions  of  exception 
handling*  This  will  be  true  because  an  errant  program  will  be 
detected  when  it  accesses  memory  outside  its  limits.  The  program 
could  also  be  in  a  loop  and  doing  nothing  useful.  Illegal  accesses 
will  cause  a  direct  trap  to  the  kernel.  A  loop  will  cause  no  harm 
to  the  system  except  for  reduction  in  useful  resources;  the 
scheduler  will  only  allow  part-time  access  to  the  processor  for  the 
looping  process.  It  may  cause  serious  harm  to  the  user  because  the 
process  is  not  performing  its  function;  methods  for  detecting  such 
processes  will  be  investigated.  If  the  process  is  capable,  it 
should  handle  final  actions  or  exceptions  because  exceptions  are 
synchronous  events  that  occur  every  time  the  program  runs.  However, 
the  program  may  not  be  capable  of  recovery  and  the  OS  may  abort  the 
process.  In  this  case  the  task,  manager  is  invoked  and  the 
contingency  handler  notified;  survivability  now  requires  action. 
Permitting  a  process  to  handle  its  exceptions  is  common  practice, 
usually  limited  by  requiring  that  exceptions  occurring  in  the 
exception  handler  cause  an  immediate  abort. 

Synchronization  of  remote  cooperating  processes  must  be  handled  by 
the  network  Interface.  Blocking  options  on  messages  is  simplest. 
Techniques  such  as  this  may  have  too  much  overhead  for  processes  in 
the  same  PE  that  need  to  synchronize.  We  assume  again  that  these 
local  synchronizations  are  common  and  we  need  to  consider  special 
actions  for  them;  e.g.,  a  set  of  kernel  primitives  implementing 
event  flags.  This  type  of  synchronization  is  used  in  contemporary 
OS  (v.  DEC  RSK11M).  User  programs  that  employ  basic  synchronization 
primitives  like  semaphores  or  event  flags  can  be  difficult  to 
understand  and  maintain  [BETA  79].  Synchronization  is  a  prime 
example  of  a  side-effect.  Provision  of  synchronization  by 
constructs  in  the  language  employed  by  the  user  in  writing  the 
program  leads  to  programs  that  work  sooner  and  are  more  easily 
maintained.  This  puts  the  work  of  providing  the  synchronization  on 
a  system  process  implemented  in  the  run-time  support  of  the 
language. 

3.3  Task  Management 

Task  Management  is  a  distributed  function;  recall  that  a  basic 
property  of  the  design  is  that  no  process  needs  to  know  where 
another  process  is  located  in  order  to  call  that  process.  It  has 
been  divided  into  two  sub-functions  Implemented  by  the  Task  Manager 
(TM)  and  the  Task  Assignment  Manager  (TAM),  respectively,  although 
these  processes  call  on  other  processes  for  support.  Task  manage¬ 
ment  requires  global  knowledge  and  is  a  Control-VIP  function. 
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The  TM  Is  replicated  la  every  FE  and  oversees  task  management  for 
the  particular  PE.  The  TAM  is  a  process  that  maintains  global 
knowledge  about  the  location  of  processes  In  the  CCIU.  It  oversees 
locating  processes  as  well  as  possible  migration  of  processes;  the 
TAM  assigns  responsibility  to  a  particular  PE  for  process 
execution.  TAM  procedures  exist  in  every  PE  to  ensure 
survivability.  However,  as  described  below,  the  TAM  in  only  one  PE 
is  fully  functional  at  any  one  time. 

3.3.1  TAM  Overview 


The  TAM  is  logically  in  a  Control-VIP  distributed  over  several 
PE's.  The  TAM  database  in  the  configuration  tables  includes  a 
dictionary  to  the  location  of  processes  and  their  backups.  Section 
2  of  this  document  has  described  a  hierarchical  network  structure 
based  on  layers  of  sub-networks  each  of  which  is  expected  to 
contain  internally  most  communication  messages  among  the  PE's 
within  its  own  layer.  The  sphere  of  control  of  a  Control-VIP  that 
contains  a  given  TAM  will  extend  over  one  of  these  subsidiary 
networks;  the  configuration  table  will  normally  contain  information 
regarding  processes  in  that  layer.  In  the  event  that  a  large 
amount  of  traffic  exists  between  TAMS  in  different  Control-VIP's, 
special  entries  in  the  configuration  table  can  be  set  up  for 
individual  cases.  The  limitation  on  configuration  tables  to  one 
network  layer  necessitates  that  the  TAM  use  the  contract  net 
protocol  (described  later)  to  locate  processes  outside  of  its  own 
Control-VIP.  In  the  ensuing  description  of  the  TAM,  the  discussion 
is  primarily  about  the  action  of  the  TAM  in  controlling  task 
assignment  in  a  single  Control-VIP;  this  is  expected  to  be  the 
normal  case. 

Methods  are  provided  for  regenerating  the  TAM  database  in  case  it 
is  destroyed  by  PE  failure.  Regeneration  must  be  a  last  resort 
recovery  procedure  because  of  the  time  and  communication  resources 
it  uses  up.  On  the  other  hand,  the  database  for  the  TAM  must  be  up 
to  date  at  all  times.  To  minimize  the  problem  of  update  and 
concurrency  control  for  this  database,  the  TAM  primarily  executes 
in  a  single  PE.  The  TAM  processes  are  backed  up  in  several  or 
possibly  all  PE's  to  ensure  system  integrity.  All  PE's  will  be 
running  a  small  part  of  their  TAM  code  to  communicate  with  the 
primary  TAM  process  and  to  monitor  for  the  continued  existence  of 
that  primary  process. 

3.3.2  TAM  Establishment 

If  the  CCIU  is  operational,  a  TAM  exists.  If  the  PE  that  contains 
the  current  TAM  fails,  it  is  necessary  to  reestablish  a  TAM.  A 
procedure  will  exist  for  Identifying  a  new  TAM  that  is  triggered 
when  some  process  attempts  to  access  the  TAM  and  finds  that  none 
exists.  This  process  of  rsestablishlng  the  TAM  may  take  time 
because  it  is  possible  the  database  in  the  new  TAM  is  out  of  date. 
A  way  of  handling  the  situation  and  preventing  it  from  arising  is 
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for  Che  residual  TAM  in  each  PE  to  notify  che  primary  TAM  of 
changes  in  processes  it  contains,  and  in  case  of  a  new  TAM  to 
identify  all  processes.  The  procedure  for  backup  process  migration 
is  implemented  through  the  TAM  (it  is  initiated  by  the  contingency 
handler)  and  therefore  some  of  the  communication  traffic  in 
exchanging  process  location  data  is  alleviated.  The  alternative 
arrangement  of  having  completely  replicated  databases  that  are 
updated  every  time  a  configuration  change  occurs  is  presently 
considered  to  have  too  high  a  communication  overhead. 

The  procedure  for  reestablishing  a  TAM  after  a  failure  is  not 
simple.  A  possible  complication  is  that  two  PE's  recognize  there  is 
no  TAM  simultaneously  and  both  start  recovery  procedures.  Care  must 
be  taken  that  two  TAM's  are  not  Inadvertently  established.  Some 
algorithms  applicable  to  the  problem  are  described  in  [LUNN  81]  and 
[GARC  82]. 

If  a  single  PE  is  running,  it  uses  its  own  TAM  module  with  the 
standard  configuration  table  subject  to  the  knowledge  only  one  PE 
exists.  In  this  situation  the  TM  does  all  the  assignment  work. 
When  a  PE  is  started  (cold  start),  the  operator  may  or  may  not 
elect  to  join  the  network.  If  the  PE  joins  the  network,  its  first 
action  is  to  let  the  network  know  that  it  is  on-line,  and  then 
locate  a  TAM.  If  no  TAM  exists  (because  it  has  just  failed)  the 
situation  previously  mentioned,  where  more  than  one  PE  discovers 
there  is  no  TAM,  can  arise.  A  TAM  can  effectively  "disappear”  if  a 
problem -in  the  communication  subnetwork  causes  its  PE  to  become 
disconnected. 

If  a  failure  occurs  in  such  a  way  that  the  network  becomes 
fragmented  into  two  or  more  parts,  another  serious  recovery 
problem  arises.  In  this  case  the  recovery  procedures  will  result  in 
TAM's  existing  in  each  network  fragment.  Assuming  the  network  again 
becomes  reconnected,  synchronization  of  the  two  TAM  databases  and 
"retirement"  of  one  of  the  TAM's  must  occur.  The  exact  recovery 
procedures  for  all  of  these  abnormal  conditions  have  not  been 
worked  out  in  detail. 

TAM  Functions 

The  exact  way  the  TAM  performs  its  location  and  assignment 
functions  are  dependent  upon  the  degree  of  decentralization  of 
control.  Two  different  approaches  are  used  by  the  CCIU.  In  the 
first  approach,  the  TAM  locates,  by  a  series  of  query  messages,  a 
PE  that  is  willing  to  execute  a  desired  process.  If  several  PE's 
are  willing,  the  TAM  makes  a  decision  based  on  any  information 
known  to  it  or  supplied  in  the  acceptance  messages  from  the  several 
PE's.  After  this  decision  is  made  the  TAM  notifies  the  selected 
PE.  This  protocol  for  locstlng  a  PE  is  called  the  Contract  Net 
Protocol  (CNP)  and  its  details  are  expanded  in  a  later  section. 


In  the  second  approach,  Che  TAM  consults  the  configuration  table 
and  arbitrarily  selects  a  PE  known  to  have  the  resources  to 
accomplish  the  task.  This  PE  is  directed  to  run  the  process*  It  aay 
be  incapable  of  doing  so  in  which  case  it  notifies  the  TAM  and 
another  PE  must  be  selected.  This  technique  is  known  as  the 
directed  protocol. 

It  is  clear  that  the  contract  net  protocol  has  considerably  aore 
aessage  overhead  than  the  directed  protocol.  It  is  a  auch  aore 
“decentralised'*  approach  because  the  TAM  does  not  need  to  know 
initially  the  location  of  a  suitable  PE  or  even  if  one  exists. 

3. 3. A  Task  Manager 

The  TM  is  closely  linked  to  the  TAM  but  it  exists  to  control  task 
asslgnaent  in  the  particular  PE,  and  perhaps  to  aanage  tasks  via 
the  CNF.  The  TM  knows  which  processes  are  resident  in  the  PE  and 
aay  not  notify  the  TAM  at  all  if  it  needs  to  run  one  of  them.  Such 
an  action  is  expedient  to  decrease  communication  overhead;  it  does 
not  provide  a  global  optimisation  to  run  the  process  in  the  PE  that 

is,  (through  some  criterion),  aost  suitable  at  the  given  time.  In 
case  of  PE  overload,  the  TM  aay  still  decide  to  notify  the  TAM  so 
that  a  system-wide  decision  can  be  aade  on  what  action  to  take. 
The  continued  use  of  the  TAM/TM  processes  during  the  tlae  that  a 
process  is  running,  and  communicating  with  the  process  that  started 

it,  is  an  unnecessary  load  on  the  system.  Therefore,  one  function 
of  the  TM  is  to  set  up  addresses  for  messages  to  pass  from  one 
process  to  the  other  for  communicating  control  messages  and  data. 
Such  an  address  is  a  capability  for  one  process  to  communicate  with 
another. 

3.3.5  TAM  Protocols  for  Communication 


This  section  describes  the  two  protocols  by  which  the  TAM  locates  a 
PE  capable  of  accomplishing  a  task;  the  TAM  then  assigns  it 
responsibility  for  running  the  appropriate  process. 

3. 3. 5.1  Contract  Net  Protocol  [SMIT  791 

This  is  a  protocol  where  the  initiator  (a  TAM),  issues  a  task 
announcement  either  to  all  PE's  or  to  PE's  on  a  bidders  list  pre¬ 
viously  established  by  the  initiator.  PE's  receiving  the  announce* 
ment  may  respond  with  a  bid.  After  a  certain  tlae  determined  by 
the  initiator  (that  can  be  stated  in  the  announcement),  the  initia¬ 
tor  selects  a  bidder  using  an  internal  criterion  for  establishing 
the  "best"  bid.  Then  the  selected  PE  does  the  task. 

This  protocol  permits  nearly-coaplete  autonomy  of  the  participating 
processors,  automatically  exploits  parallelism  in  the  bidding 
process,  and  is  structurally  rich  enough  to  support  security  and 
privilege  levels  of  task  execution.  It  is  compatible  with  priority 
levels,  nonhomog eneous  processor  resources,  distributed  execution 
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of  tasks,  and  ocher  peculiarities  of  che  distributed  computing 
environment. 

A  typical  task  announcement  would  Include  an  eligibility- 
specification  reflecting  resource  requirements  for  the  task.  The 
task  announcement  would  also  Include  an  abstraction  of  the  task 
adequate  for  che  bidder  to  determine  its  eligibility,  a 
specification  for  the  information  required  in  the  bid,  and  a  time 
by  when  the  bid  must  be  made  if  the  processor  so  intends. 

The  establishment  of  a  bidder's  list  (a  TAM-peculiar  function), 
requires  a  special  type  of  task  announcement  giving  eligibility 
specifications  and  cask  abstractions,  but  not  requiring  the  bidder 
to  commit  itself  to  accomplishing  the  task  at  present  . 

A  bid  would  provide  the  requested  information  and  its  Issuance 
would  commit  the  processor  to  do  the  task.  The  Issuance  of  the  bid 
requires  estimation  of  its  future  processing-load  by  the  Issuing 
processor.  The  initiator  should  issue  a  task  award  message  so  the 
several  PE's  that  have  issued  bids  do  not  continue  to  commit 
resources  for  a  job  awarded  elsewhere. 

3. 3* 5. 2  Directed  Protocol 


This  is  a  protocol  where  the  TAM  directs  a  PE  to  accomplish  a  task. 
The  PE  selected  by  the  TAM  is  determined  from  the  CCIU  configura¬ 
tion  tables. 

A  PE  must  have  the  capability  to  refuse  the  task;  it  may  be 
Incapable  of  doing  it.  The  TAM  must  be  capable  of  coping  with  the 
conditions  resulting  from  such  a  refusal.  A  PE  may  find  it 
undesirable  or  impossible  to  do  a  task  for  several  reasons: 

(1)  It  may  not  have  the  facilities,  either  data  or  process  code, 
to  accomplish  the  task. 

(2)  It  may  be  overloaded  with  current  processes  of  equal  or  higher 
priority. 

(3)  It  may  anticipate  that  overload  will  exist  in  the  near  future. 

(4)  It  may  anticipate  that  some  resource,  say*  disk  storage  space, 
will  be  exhausted  by  the  task  making  it  impossible  to 
complete. 

'Item  (4)  above  will  require  an  absolute  refusal  to  be  Issued.  In 
the  case  of  item  (1),  it  is  possible  that  the  missing  resource  can 
be  sent  from  some  other  processor  if  that  other  processor  is  unable 
to  do  the  job  itself.  In  all  of  (1)  to  (3),  however,  a  system 
decision  dependent  on  loading  and  priorities  of  many  PE's  is 
needed.  Consequently,  it  is  part  of  the  TAM  function  to  make  this 
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decision.  The  PE  elements  do  not  possess  the  lnforaetlon  or 
evaluative  techniques  required  for  the  decision. 

3.4  System  Status  Monitor 

The  system  status  monitor  module  knows  the  status  of  the  system.  It 
has  a  local  aspect,  keeping  track  of  the  status  of  resources  in  the 
PE,  and  a  distributed  aspect  involving  knowledge  of  the  resourcea 
of  other  PE's  In  the  Control-VIP. 

The  system  status  monitor  Is  the  module  that  maintains  the 
configuration  tables.  These  tables  Include  the  process  location 
table  containing  information  of  the  locating  of  proceeses  and 
their  backups.  It  also  contains  the  behavioral  template  described 
below.  Note  the  system  status  monitor  Is  the  only  module  actually 
accesseslng  the  configuration  tables.  411  requests  for  Information 
go  through  it  simplifying  Implementation  of  any  necessary  changes 
In  details  of  how  information  Is  stored. 

3.4.1  Behavioral  Template 

The  behavioral  template  describes  the  Initial  configuration  of  the 
CCIU  PE  as  determined  by  the  CCIU  Configuration  Controllers  (see 
Section  6)  from  knowledge  of  particular  PE  hardware  and  software 
reaourcea.  The  template  also  contains  global  information  regarding 
the  location  of  CCIU  proceeses  and  functions.  Thus,  the  template 
Is  part  of  a  coutrol-VIP  and  Is  a  distributed  database. 

The  CCIITs  configuration  will  change  during  Its  existence  because 
of  PE'a  that  have  been  taken  out  of  service,  PE's  that  are 
inaccessible  for  some  reason,  etc.  The  ectual  configuration  may 
also  change  because  system  loading  on  a  given  PE  may  make  It 
expedient  to  migrate  some  process  from  one  PE  to  another. 
Therefore,  the  current  configuration  may  differ  from  the  template. 

It  Is  a  system  goal  to  approach  the  template  as  closely  as  possible 
during  Its  operation.  For  example,  if  a  PE  is  not  available 
survivability  may  require  the  backup  of  Its  functions  to  be 
migrated  from  one  PE  to  another.  The  code  could  be  obtained  from 
the  PE  where  the  function  Is  currently  executing  or  from  another 
backup  PE  If  multiple  beckups  exist. 

Configuration  Tables 

As  the  CCIU  evolves  during  Its  operation,  the  actual  configuration 
will  be  stored  In  the  current  configuration  tables  maintained  by 
the  system  status  monitor. 

Resource  Manager 

The  resource  manager  Is  the  module  that  manages  allocation  of 
memory,  disk  space,  processor  usage  and  other  PE  resources.  Other 
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modules  can  request  tbeee  resources;  they  will  be  allocated 
depending  on  availability  and  priority  of  the  requester.  The 
resource  manager  therefore  contains  the  scheduler  for  the  processes 
running  on  the  systea;  the  actual  context  switch  to  run  another 
process  is  bandied  by  the  kernel.  The  resource  manager  is  also 
queried  by  the  TAM  to  determine  if  resources  for  a  new  process 
whose  activation  is  requested  by  another  PB  are  available. 
Although  the  resource  manager  is  primarily  a  local  process,  it  has 
a  distributed  aspect  residing  in  a  control-PIP.  In  order  to  con¬ 
trol  its  local  resources  the  resource  manager  must  be  cognisant  of 
other  resources.  It  may,  for  example,  find  it  desirable  to  migrate 
a  process  to  another  location  to  reduce  the  local  loading. 

3.6  Contingency  Handler 

The  contingency  handler  activates  backup  modules  and  controls  the 
allocation  of  backups  in  the  event  of  PB  failures. 

A  primitive  form  of  contingency  handler  existed  in  the  Demo  1  CCP; 
the  contingency  handler  consisted  of  a  1-element  table  that  indi¬ 
cated  PB  state. 

3.6.1  gg.  Faiiurg 

If  a  PE  failure  is  datected  the  contingency  handler  is  notified  and 
consults  the  configuration  table  to  determine  if  the  particular  PB 
is  a  backup  for  any  function  in  the  failed  PB.  In  this  ease,  the 
task  manager  is  notified  to  schedule  the  particular  function  for 
this  PE. 

This  type  of  activation  places  the  burden  of  determining  the 
correct  startup  procedure  on  the  function  itself.  Startup  may 
differ  radically  depending  on  the  function.  In  particular,  some 
functions  may  only  require  a  cold  start  while  others  may  need 
information  from  the  user  input  up  to  the  present  time.  In  the 
latter  case  the  function's  database  needs  to  be  updated  in  the 
backup  PE's  as  the  function  runs.  All  of  these  situations  are 
specific  to  the  particular  function. 

3.6.2  Additiml  ggcfcw 

The  contingency  handler  needs  further  action  to  determine  whether 
or  not  an  additional  backup  should  be  instituted.  In  some  cases,  a 
function  may  already  have  an  additional  backup.  The  desirability  of 
additional  backup  is  examined  and  if  necessary  the  contingency 
handler  selects  an  additional  PB  and  oversees  the  installation  of 
backup  capability  in  that  PB.  This  action  can  necessitate 
transferring  code  from  one  PE  to  another  or  notifying  an  operator 
to  take  an  action  to  retrieve  code  from  off-line  backup  storage. 
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Technique*  for  selection  of  e  new  backup  PE  need  further  research. 
The  abilities  of  a  PE  to  perform  the  work,  the  load  on  the 
reasining  PE's,  and  the  amount  of  work  needed  to  secure  a  valid 
backup  are  all  involved.  In  addition,  the  contingency  handler  must 
not  impose  too  much  overhead  on  the  particular  PE  where  it  is 
running  [MAJU  801.  It  is  expected  that  heuristic  search  methods 
may  be  useful. 
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4.0  The  CCIU  Database  Management  System 
4.1  Introduction 

The  CCIO  Oetebeee  Menage* ent  System  (QMS)  Is  a  distributed  system 
that  manages  data  at  all  levels  of  the  Army  command.  Examples 
are  the  description  of  the  CCIU  configuration,  the  field  locations 
information,  manpower  and  other  logistic  information,  map  data, 
electronic  mall,  summary  data,  and  all  database  transactions  used 
to  manipulate  field  data. 

The  goals  of  the  OMS  are:  to  provide  fast  access  to  data,  to 
maintain  security.  Integrity,  and  availability  of  data,  and  to 
provide  data  manipulation  capabilities  such  as  data  reduction  and 
data  integration.  DMS  is  unique  among  database  systems  in  that  it 
is  required  to  be  highly  mobile  and  survivable. 

The  data  managed  by  DMS  is  subdivided  into  two  classes:  user  data 
and  system  data.  User  data  consists  of  field  data  and  knowledge^ 
base  data.  The  field  data  includes  data  squired  during  operations 
such  as  sensor  data  (e.g.,  radar  information),  reports,  messages, 
and  saved  data  products  (e.g.,  CRT  images,  tables).  The  knowledge¬ 
base  contains  invariant  data  that  are  loaded  at  the  initialization 
of  the  CCIU  and  serve  as  reference  data  (e.g.  computation  tables). 
System  data  is  the  data  necesary  to  control  the  CCIU.  This  data  is 
not  accessible  by  the  user.  It  includes  among  others  the  behavioral 
template  (see  Section  3.0)  and  configuration  tables. 

DMS  has  two  central  functions:  the  first  is  to  provide  descrip¬ 
tions  of  the  available  data.  This  is  the  data  dictionary 
function.  It  is  used  as  a  roadmap  to  the  design,  use  and  evolution 
of  field  user  views.  The  second  function  of  DMS  ie  to  manage  data 
storage,  manipulation,  integrity,  and  security,  as  well  as  data¬ 
base  concurrency.  This  is  called  the  physical  view  of  DMS;  there 
is  only  one  physical  view  representing  the  underlying  structure  of 
the  union  of  all  field  user  views. 

There  has  been  a  significant  amount  of  research  addressing  various 
issues  in  distributed  databases.  Results  of  this  research  have 
been  reported  in  numerous  papers.  For  the  sake  of  brevity,  these 
results  are  only  referenced  in  this  report.  It  is  assumed  that 
whenever  appropriate  commercial  database  software  and  conventional 
software  engineering  techniques  will  be  used.  The  references  given 
are  not  intended  to  be  complete;  they  only  indicate  the  large  body 
of  computer  science  literature  relating  to  DMS.  For  a  general 
discussion  of  distributed  database  management,  see  [FARB  75]  and 
[GRAY  79].  Transaction  processing  in  distributed  systems  is  dis¬ 
cussed  in  [GRAY  81].  Locking  mechanisms  are  discussed  in  [CHU  74], 
[MENA  78],  and  [MENA  79].  Query  distribution  is  the  topic  of  [CHU 
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79].  Finally,  various  recovery  mechanisms  are  discussed  In  [HAMM 
78]. 

The  Semantic  Peer  Interface 

DMS  aust  be  usable  by  non-database  specialists.  A  number  of  recent 
database  research  efforts  have  concentrated  on  developing  semantics 
database  models.  These  models  attempt  to  embed  the  semantics  of  an 
application  environment  within  the  database  schema  by  providing 
high-level  data  structuring  and  manipulation  primitives.  The  goal 
is  to  make  the  database  readily  usable  and  evolvable  by  non-expert 
users.  DMS  utilizes  a  semantic  database  interface  to  field  user 
views.  Such  an  Interface  makes  the  database  specification  easily 
accessible  during  view  formation  and  use. 

Rather  than  basing  their  modeling  constructs  on  the  logical  record 
(as  the  relational,  hierarchical,  and  network  models  do),  semantic 
models  typically  represent  the  application  environment  as  a 
collection  of  objects.  Objects  have  attributes  and  are  classified 
according  to  types  and  subtypes.  Semantic  models  provide  static 
and  dynamic  capabilities.  The  designer  provides  high-level,  appli¬ 
cation-specific  database  transactions  within  the  database  schema 
that  the  user  can  directly  initiate.  DMS  provides  a  unified  set  of 
semantic  static  and  dynamic  structures  to  model  control  and  field 
user  views.  A  summary  of  essential  techniques  and  recent  research 
in  semantic  database  models  Is  provided  in  [KING  82]. 

Control  views  are  the  views  of  the  database  used  by  the  system. 
Within  the  OMS  they  are  modeled  using  special  network  constructs. 
The  designer  of  a  CCIU  configuration  specifies  such  entitles  as  the 
network  PH  names,  PE  locations,  and  communication  links  between 
PB"s.  The  constructs  available  to  specify  the  static  aspects  of 
field  data  are  essentially  a  unification  and  simplification  of 
those  found  in  various  semantic  database  models.  The  dynamic 
aspects  are  expressed  in  a  simple  programming  language  containing 
primitives  that  directly  manipulate  semantic  static  constructs. 
Similar  constructs  are  used  to  model  user  views.  These  views 
consist  of  objects  and  transactions.  There  are  two  types  of  trans¬ 
actions,  manipulation  transactions  that  update  data,  and  perusal 
transactions  that  do  not. 

OMS  Includes  an  Interactive  facility 'for  browsing  the  semantic 
dictionary  to  define  field  user  views.  A  field  user  view  consists 
of  a  number  of  disjoint  logical  schema,  each  formed  using  the 
semantic  user  Interface.  The  deflner  of  an  original  view  will  only 
allow  access  to  perusal  transactions  and  may  not  Include  manipula¬ 
tion  transactions  In  the  field  user  view  available  In  the  control 
view.  Any  user  can  define  new,  arbitrary  perusals  at  any  time,  but 
may  not  define  new  manipulations,  except  on  his  own  original  views. 
An  Interactive  facility  also  exists  for  guiding  the  user  through 
the  definition  of  new  perusals.  A  generalized  report  writer  exists 
for  formatting  data  for  output.  A  number  of  summary  functions  are 


available  for  deriving  summary  field  data*  In  summary,  ehe  DMS 
user  interface  supports  the  easy  manipulation  of  field  data  and 
“met a"  data  concerning  schema  structure. 

In  a  field  user  view,  there  are  two  varieties  of  objects:  descrip¬ 
tor  objects  are  atomic  strings  of  characters  or  numbers,  and 
generally  serve  as  symbolic  identifiers  in  a  database;  abstract 
objects  are  non-atomic  entitles,  defined  in  terms  of  their 
relationships  with  other  objects  through  attributes.  An  attribute 
is  a  mapping  from  one  type  of  object  to  another,  and  is  generlcally 
associated  with  a  type;  at  any  given  time,  each  object  of  the 
modified  type  (attribute  domain)  has  a  specific  attribute  value 
that  is  a  subset  of  the  modifying  type  (attribute  range).  If  an 
object  uniquely  identifies  an  instance  of  an  object  type,  it  is  a 
primary  attribute;  otherwise,  it  is  a  dependent  attribute.  Attri¬ 
butes  have  a  number  of  options  that  enforce  Integrity  constraints; 
for  example,  attributes  may  be  defined  as  being  single-valued  or 
multi-valued,  nonmull,  etc.  Subtypes  of  descriptor  and  abstract 
object  types  can  be  defined  by  specifying  predicates  on  the  values 
of  attributes,  or  by  performing  summary  operations  on  the  instances 
of  existing  types.  A  subtype  inherits  all  of  the  attributes  of  its 
parent  type,  and  may  have  new  attributes  as  well. 

Field  data  consists  of  raw  and  derived  data  (subtypes).  An  example 
of  raw  data  object  is  printing-devices.  Printing  devices  would 
perhaps  have  attributes  describing  the  type  of  output  they  produce 
(device-type),  the  computers  they  may  interface  with  (required- 
host),  and  the  identification  number  of  the  devices  (device- 
number).  Line-printers  is  an  example  subtype,  derived  with  a 
predicate  on  device-type.  Another  example  abstract  object  type  is 
radar-images,  with  the  attribute  image-type  serving  as  a  unique 
identifier,  and  classification  serving  as  a  dependent  attribute 
that  gives  a  numerical  indication  of  the  threat  indicated  by  each 
radar  image.  An  example  subtype  is  summary— radar-data  consisting 
of  one  radar  image  per  image  type;  that  image  represents  the  nume¬ 
rical  average  (in  terms  of  classification)  of  the  threat. 

A  transaction  is  a  high-level  manipulation  of  an  event  database. 
Each  transaction  definition  specifies  a  particular  generic  type  of 
transaction  by  defining  the  following:  a  collection  of  parameters, 
that  are  of  descriptor  or  abstract  object  types;  a  collection  of 
working  subtypes  that  define  the  object  subtypes  the  particular 
transaction  manipulates  and  a  collection  of  actions.  An  action  is 
either  an  Invocation  of  another  transaction  or  an  invocation  of  a 
primitive  data  operation  (e.g.,  add  instance  to  type,  r'emove 
Instance  from  type,  update  attribute);  the  actions  of  a  transaction 
are  structured  using  sequencing,  selection/conditional,  and  itera- 
tion  control  structures.  Transactions  are  organized  in  a 
type/subtype  hierarchy,  in  a  manner  similar  to  the  object 
type/ subtype  hierarchy;  one  transaction  is  a  subtype  of  another  if 
the  value  types  of  the  parameters  of  the  former  are  subtypes  of  the 
value  types  of  the  parameters  of  the  latter,  and  if  the  actions  of 
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the  former  ere  intuitively  e  speciel  ceae  of  the  actions  of  the 
letter. 

A  restricted  fora  of  transection  la  a  perusal,  which  accommodates 
unplanned  queries  of  event  databases  and  may  not  update  data.  4 
perusal  Is  the  specification  of  an  object  subtype  at  database 
access  time;  It  typically  consists  of  a  subtype  of  descriptors.  An 
example  perusal  might  be  the  subtype  of  Integers,  consisting  of  all 
device-numbers;  the  number  describes  a  printing  device. 

An  example  application  event  type  Is  distrlbute-map-data,  with 
parameter  location  (the  identifier  needed  to  isolate  a  network  PE). 
The  working  subtypes  of  distribute— map-data  may  be  subtypes  of  the 
object  type  map-data,  which  the  various  subtypes  isolated  by  exami¬ 
ning  an  attribute  called  distribution-indicator.  The  actions  of 
distrlbute-map-data  would  be  to  Invoke  the  network  to  ship  the 
required  map  data  to  each  PE.  Presumably,  this  event  would  be 
initiated  by  a  central  map  data  authority.  Another  possibility: 
subtypes  of  the  event  would  be  Initiated  by  the  commanders  at  the 
various  PE's.  That  Is,  a  commander  would  request  current  map  data 
on  his  location  whenever  It  Is  desired. 

Field  Peer  Views  and  Physical  Views 

DMS  data  sharing  is  defined  along  two  dimensions:  the  first 
measures  the  degree  of  sharing,  and  the  second,  the  level  of 
command  where  the  data  sharing  takes  place.  With  respect  to  the 
first,  field  user  views  may  consist  of  either  primitive  data  schema 
or  unification  of  one  or  mors  preexisting  views.  The  field  user 
views  have  various  security  levels  assigned  to  them.  One  security 
level  means  that  no  field  user  other  than  the  original  owner  of  the 
view  may  use  It.  (The  control  views  and  physical  view  always  have 
this  security  level).  Other  security  levels  Indicate  what  clear¬ 
ance  Is  necessary  to  use  the  view.  A  field  commander  can  protect 
certain  data  from  sharing  by  forming  a  separate  view  describing  It, 
and  giving  that  view  a  high  security  level.  Some  forms  of  data  may 
be  so  confidential  that  even  its  description  cannot  be  made 
‘‘public”;  this  type  of  data  would  not  be  made  available  for  sharing 
by  anyone.  A  field  user  view  definition  also  Indicates  the  loca¬ 
tion  of  any  other  views  used  to  create  the  given  view. 

If  a  user  view  can  be  used  In  other  views  (if  It  has  any  security 
level  other  than  the  most  restrictive),  then  a  description  of  that 
view  appears  In  the  data  dictionary.  The  data  dictionary  is 
available  for  reading  to  all  users,  It  indicates  the  structures  of 
the  various  views,  their  location,  and  their  security  levels.  To 
build  a  new  view  a  user  can  either  define  new  data  types  and 
transactions,  and/or  consult  the  control  view  and  request  the 
network  to  provide  access  to  existing  user  views.  A  new  view  Is 
the  sum  of  any  new  or  borrowed  views  that  fora  It;  no  specific 
operations  exist  for  merging  views.  If  a  user  view  designer  wishes 
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to  coapress  or  suaaarlze  data,  it  oust  be  done  through  the  DMS  user 
interface. 

As  part  of  its  operation,  the  CC1U  would  collect  live  data  (radar, 
aap,  order  of  battle,  etc.)  and  produce  suaaary  data.  A  typical 
field  view  would  consist  of  two  separate  views,  one  representing 
the  data  collection  and  suaaary  data  production  events  and  corre¬ 
sponding  objects.  The  other  view  would  have  a  lower  security 
levdl,  and  would  provide  suaaary  data  perusing  events  for  other 
users  to  initiate.  Each  field  user  provides  other  users  with  the 
capability  to  read  his  data.  A  given  user  aay  also  integrate  other 
existing  field  user  views  into  his  own.  These  "borrowed’*  views 
would  be  used  to  direct  the  updating  of  data  the  given  user  is 
collecting;  for  exaaple,  the  producer  of  aap  data  aay  need  to  read 
suaaary  radar  data. 

The  other  spectrua  along  which  data  sharing  is  aeasured  is  the 
level  of  coaaand  at  which  the  data  is  being  used.  Very  possibly,  a 
field  coaaander  which  allows  sharing  only  on  application  events 
that  did  not  update  his  data.  Any  other  events  would  be  available 
for  use  by  other  coaaanders,  at  any  level  of  coaaand.  Also, 
coaaanders  above  hla  could  alaost  certainly  have  coaplete  access  to 
all  his  user  views.  Most  likely,  higher  coaaand  levels  would 
augaent  their  views  with  events  that  condense  the  data  in  lower 
views;  this  would  allow  coaaanders  to  focus  on  major  issues.  Thus, 
views  are  likely  to  be  grouped  into  a  tree,  with  each  coaaander 
having  access  to  the  views  of  all  individuals  below  hla.  However, 
in  order  to  avoid  duplication  of  data,  all  users  (especially  those 
absorbing  visws  froa  lower  levels  of  coaaand)  would  aost  likely 
derive  all  their  views  froa  original  views.  In  other  words,  if  two 
users  have  partially  overlapping  views,  and  if  they  have  a  comm  n 
coaaander,  that  coaaander  would  have  two  logical  "copies"  of  part 
of  his  data  if  ha  were  to  blindly  place  both  views  in  his  own. 

The  physical  view  is  not  visible  to  field  users.  It  serves  as  a 
logical  representation  of  the  physical  state  of  the  database  and 
assists  the  physical  designer  in  the  process  of  iapleaenting 
sea  an  tile  data  constructs.  It  describes  the  location  of  the  data 
represented  by  each  view,  Including  inforaatlon  concerning  duplica¬ 
tion  of  data,  and  database  control.  The  physical  view  is  therefore 
aade  up  of  a  number  of  physical  scheaa.  The  separation  of  data 
views  from  the  data  (called  data  Independence)  provides  for  mobili¬ 
ty:  as  the  CCIU  configuration  evolves,  data  can  be  shipped  between 
processors  on  the  network  without  the  user's  awareness.  In  other 
words,  the  user  knows  what  processor  aaintalns  the  Interface  to  his 
view  (the  scheaa),  but  need  not  be  aware  of  the  location  of  the 
actual  data.  Duplication  of  data  provides  for  survivability  and 
reliability  any  nuaber  of  duplicate  physical  scheaa  can  be  kept  and 
DMS  will  coordinate  their  correctness;  DMS  will  automatically  swap 
in  a  duplicate  if  a  data  set  is  lost  or  daaaged.  Like  data  inde¬ 
pendence,  duplication  is  invisible  to  the  field  user. 
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Physical  schema  describe  the  raw  field  data  existing  on  the  CCIU 
network.  Physical  schema  describe  the  physical  level  of  field 
data,  and  the  physical  view  is  a  control  view  of  the  physical 
level.  Logical  schema  are  semantic  dictionaries  of  the  field  data, 
as  viewed  at  the  user's  level.  Logical  schema  provide  a  descrip¬ 
tion  of  the  structure  of  available  data,  and  a  description  of 
predefined  transactions  for  manipulating  data.  (Note:  a  distinc¬ 
tion  must  be  made  between  a  database  schema  and  the  data;  the  form 
of  actual  data  is  described  Immediately  below.) 

The  physical  data  level  is  a  machine— independent  organization  of 
data,  described  in  terms  of  the  relational  model.  It  serves  as 
the  starting  grounds  for  the  physical  lmplementer  of  a  CCIU 
system.  It  also  provides  a  framework  for  representing  the  high- 
level  semantic  constructs  in  a  form  closer  to  typical  data 
structures  and  access  mechanisms.  (It  is  logical  to  use  a  commer¬ 
cial  relational  database  system  as  the  underlying  database;  in  this 
way,  the  translation  from  the  physical  view  to  an  actual  database 
would  be  fairly  simple.)  All  logical  views  of  capability  and  field 
data  can  be  decomposed  into  physical  views.  (Although  logical 
views  of  field  data  may  be  described  in  terms  of  other  logical 
views,  and  not  directly  in  terms  of  physical  views.)  All  types  and 
subtypes  are  mapped  into  relations;  attributes  are  mapped  into 
columns,  and  attribute  domains  are  mapped  into  columns  domains. 
Options  are  associated  with  columns,  and  are  enforced  procedurally 
at  data  manipulation  time.  Each  unique  object  in  the  database  is 
represented  as  a  unique  internal  identifier;  anywhere  a  given 
identifier  occurs,  it  represents  the  same  object.  Transactions  are 
represented  as  source  code  in  a  host  language  (e.g.,  Ada);  that  is, 
all  transactions  are  compiled  into  a  standard  programming  language. 

The  physical  level  also  addresses  a  number  of  implementation  consi¬ 
derations.  As  redundancy  is  an  important  mechanism  in  DMS,  each 
physical  schema  is  given  a  name  and  a  version  number.  All  versions 
with  the  same  name  are  considered  identical  at  all  times. 

Each  physical  schema  is  also  given  a  location  name,  in  order  to 
facilitate  network  transmissions  of  data  updates.  (Logical  schema 
do  not  require  location  names,  as  the  logical  level  of  data  is 
available  to  all  users  and  updates  are  performed  throug  the 
physical  level.)  ^ 

In  a  battle  situation,  DMS  must  provide  reliable  data  manipulation 
and  querying  facilities.  The  key  to  IMS's  reliability  lies  in  its 
semen: ic  Interface  and  strict  data  independence.  Field  users  may 
easily  construct  and  use  data  views,  and  may  specify  arbitrary 
levels  of  partial  sharing.  Disappearance  of  a  PE  is  invisible  to 
the  user  if  a  copy  of  all  required  field  and  meta  data  still 
exists.  Further,  separation  of  physical  implementation  (in  terms 
of  some  underlying  database  management  system)  and  logical  imple¬ 
mentation  decisions  (in  terns  of  a  physical  view)  provides  for 
complete  flexibility  in  evolving  a  physical  implementation  without 
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changing  the  field  user's  view  of  the  data.  In  this  way,  DMS  can 
maintain  a  reliable  view  of  the  database,  regardless  of  whether 
changes  in  field  conditions  have  resulted  in  reorganizing  field 
data  or  physical  devices. 

.4  Data  Control 


DMS  must  support  description  and  manipulation  of  a  wide  variety  of 
data.  Semantic  constructs  available  for  data  definition  and  mani¬ 
pulation  provide  simple,  uniform  techniques  for  structuring  and 
evolving  all  forms  of  data,  from  net  description  information  to  map 
data.  Similarly,  uniform  mechanisms  exist  for  controlling  update 
and  duplication  of  all  forms  of  data.  DMS  provides  reliable  data¬ 
base  mechanisms  and  wraps  them  in  a  user-friendly  interface.  This 
section  briefly  discusses  special  data  control  aspects  of  DMS: 
decentralization,  security  enforcement,  integrity  control,  data¬ 
base  locking,  and  duplication.  DMS  is  a  decentralized  database 
system.  This  means  that  updates  to  independent  field  user  views, 
the  physical  view,  or  the  control  view  do  not  have  to  be  addressed 
through  a  central  interface.  There  is  no  processing  'bottleneck": 
if  a  user  wishes  to  update  his  data  he  does  not  have  to  address  the 
network,  he  merely  performs  the  update  locally.  Cross-network 
updates  will  occur  only  when  one  user  reads  data  from  another 
user's  view,  or  when  a  duplicate  data  set  is  being  updated. 

A  security  code  is  associated  with  each  logical  view  of  field  data. 
As  a  logical  view  is  built  recursively,  it  inherits  the  strictest 
security  code  of  its  components.  Thus,  a  field  commander  may 
protect  his  data  against  use  by  other  field  commanders.  Physical 
views  also  have  security  levels  that  Identify  individuals  autho¬ 
rized  to  update  the  underlying  implementation  of  the  corresponding 
user  views.  Access  to  data  is  mediated  through  the  capability 
mechanism  of  the  operating  system  to  enforce  security.  All  data  is 
assumed  to  be  encoded;  the  user  Interface  automatically  decodes 
data,  assuming  the  user  has  proper  clearance  (that  is,  some  sort  of 
log-on  procedure). 

Most  integrity  mechanisms  are  automatically  controlled  through 
enforcement  of  attribute  options.  For  example,  restricting  an 
attribute  to  being  single-valued  or  non-null  implies  an  Important 
integrity  constraint.  DMS  could  easily  be  extended  to  Include  a 
number  o'f  other  integrity  constraints,  including  ones  that  control 
relationships  between  attributes.  This  would  mean  extending  the 
predicate  mechanism  used  to  derive  subtypes  to  include  derivation 
of  attribute  values.  For  example,  it  could  be  defined  that  the 
value  of  one  attribute  of  one  type  must  be  equal  to  the  numerical 
sum  of  two  attributes  of  another  type. 

Small  levels  of  granularity  on  locks  may  be  derived  for  pre-deflned 
transactions.  The  semantic  interface  enables  very  efficient  con¬ 
currency  control  by  examining  working  subtypes  of  the  various 
transactions  to  derive  the  exact  subtypes  and  attributes  an  appli- 
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cation  event  manipulates.  Data  contention  will  not  be  a  problem  in 
a  given  DMS  implementation;  the  owner  of  an  original  user  view  will 
probably  retain  data  update  privileges  exclusively  for  himself  and 
his  superiors.  In  other  words,  the  vast  majority  of  cross-network 
data  operations  will  consist  of  perusals  of  summary  data  that  is 
updated  in  a  periodic  manner.  (Raw  radar  transmissions  will  proba¬ 
bly  be  of  little  use  to  anyone).  Therefore,  a  large  amount  of  data 
reading  will  not  require  locking,  as  summary  data  will  be  updated 
in  batch. 

The  definer  of  a  physical  view  may  provide  for  any  number  of 
versions  of  the  view.  Because  of  its  Importance,  the  control 
view's  physical  view  is  a  likely  candidate  for  multiple  versions. 
CC1U  will  automatically  enforce  version  control,  and  will  automati¬ 
cally  locate  a  duplicate  when  a  user  attempts  to  access  a  "missing’* 
data  set.  Also,  data  may  be  archived  off-line  for  extra  protection 
against  loss* 

The  physical  lmplementer  of  a  DMS  configuration  would  normally 
define  a  number  of  duplicate  physical  views,  in  order  to  protect 
data  against  destruction.  If  a  network  PE  (computer)  "disappeared" 
during  battle,  DMS  would  automatically  locate  any  needed  duplicate 
data  sets.  Due  to  the  extreme  level  of  data  Independence,  physical 
implementation  or  network  configuration  may  be  changed  without 
effecting  the  user  views  at  all.  If  a  network  failure  or  PE 
disappearance  results  in  the  control  view  or  physical  view  being 
updated,  users  may  continue  processing  their  data  uninterrupted 
(unless  all  duplicates  of  a  data  set  or  all  paths  to  a  required 
data  set  have  been  destroyed). 

4.5  A  Note  on  Tailoring 

DMS  must  be  supported  on  a  network  of  small  machines.  Due  to  the 
necessity  of  utilizing  existing  Army  equipment,  the  various 
machines  on  the  network  may  be  a  variety  of  brands.  Further, 
commercially  available  database  management  systems  suitable  for 
small  computers  typically  do  not  support  distribution  of  data.  The 
semantic  modeling  constructs  available  in  the  data  definition  faci¬ 
lities  of  DMS  are  simple  enough  to  be  supported  in  a  minicomputer 
environment,  and  very  little  software  would  be  needed  to  support 
the  schema  merging  and  data  manipulation  operations.  The  data 
control  and  schema  definition  facilities  of  the  underlying  commer¬ 
cial  database  management  system  will  have  to  be  tailored  to  suit 
the  needs  of  DMS. 
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The  aechanisa  for  security  hoc  boon  created  in  the  deecription  of 
the  PSOS  kernel.  As  described  it  consists  of  a  capability  for 
systea  objects  unique  to  each  object  and  assigned  by  the  kernel 
when  the  object  is  created.  The  creator  possesses  the  initial 
capability  for  the  object  and  ean  instruct  the  kernel  to  grant  that 
capability  to  other  processes  as  desired.  In  the  previous 
description  reference  was  aade  to  other  possible  systeas  for 
protection. 

This  protective  technique  is  priaarily  intended  to  provide  a  secure 
operating  aystsa  where  an  erroneous  or  aalieious  process  cannot 
injure  another  process,  cannot  crash  the  systea,  and  cannot  gain 
access  to  data  if  it  has  not  been  given  a  capability  for  that 
access.  Ve  have  not,  however,  addressed  certain  other  security 
issues  of  equal  iaportanee  to  the  user.  These  issues  are  concerned 
with  the  granting  of  capabilities  to  others  by  processes  that 
legitiaately  possess  then.  A  process  aust  be  capable  of  granting  a 
capability  that  it  has  for  an  object  to  another  process  if  the 
object  is  to  be  shared.  This  situation  ean  result  in  a  capability 
being  passed  along  to  several  processes  in  order  that  they  aay 
operate  on  the  object  involved.  If  security  level  coapartaents  are 
required  it  is  iaportant  that  a  highly-classified  process  not  be 
capable  of  writing  highly  classified  data  into  a  lower  level  area 
of  classification.  Ve  believe  that  our  capability  aethod  provides 
a  framework  for  the  developaent  of  such  secure  systeas.  Finally, 
we  have  not  considered  encryption  in  any  way  since  it  is  not  within 
the  scope  of  the  project.  Possibly  encryption  could  be  used  on 
systea  data  or  on  communication  channels  between  processors. 

A  protection  problca  also  exists  with  initial  assignment  of 
-capabilities.  Capabilities  aust  be  assigned  by  the  configuration 
controllers  (sec  Section  6  }  for  the  CCIT7  systea.  Froa  the  tiae  of 
their  initial  assignaent  until  they  are  entered  into  the  .kernel 
database  they  aust  be  protected  by  aeans  outside  the  systea. 

Protection  of  the  user  interface  froa  unauthorised  use  will  be 
handled  by  the  usual  methods.  Perimeter  protection  can  be  used  for 
this  purpose  as  well  as  user  authentication  passwords. 


.0  Hnain  Pastors  and  User/Developer  Interface 

.1  Access  CUhm 

Access  to  the  CCTD  will  be  provided  for  three  classes  of  personnel. 
These  are  (1)  users,  the  noraal  user  of  the  CCIU,  (2)  configuration 
controllers,  and.  (3)  software  developers. 

>1.1  Users 

Users  of  the  CCIU  will  be  those  nil  it  ary  personnel  who  make  use  of 
the  facilities  and  information  which  the  CCIU  can  provide.  These 
users  will  interact  with  the  CCIU  through  a  specialized  directive 
command  language  that  will  in  turn  provide  access  to  sublanguages 
appropriate  to  the  particular  function  they  are  using.  This 
interaction  will  be  considered  in  more  detail  in  Section  (6.2). 
Access  to  the  CCIU  will  be  controlled  for  individuals  by  encrypted 
keys  or  passwords. 

.1.2  Configuration  Controllers 

It  is  essential  that  certain  authorized  personnel  have  more 

detailed  access  to  the  inner  mechanisms  of  the  CCIU  to  exercise 
control  over  its  internal  functions.  These  are  called 
configuration  controllers.  They  will  be  able  to  make  changes  in 
the  behavioral  template  to  provide  some  flexibility  in  the 
configuration  of  the  CCIU.  They  can,  for  example,  change  priorities 
of  functions  and  set  up  the  initial  configuration  of  backups.  A 
configuration  controller  will  also  be  able  to  cause  a  given  PE  to 
join  or  leave  the  CCIU.  In  a  full-scale  CCIU  there  will  also  be 
various  global  state  variables  which  the  CCIU  attempts  to  adjust 
for  optimal  performance.  An  example  is  the  location  of  backup  PE's 
for  a  function  that  may  need  to  change  as  PE's  are  disabled.  The 
selection  of  these  sites  should  be  an  automatic  CCIU  operation, 
based  on  existing  PE's  and  their .  traffic  loads.  The  basic 
algorithm  the  CCIU  uses  for  selection  may  contain  parameters  which 
are  selected  by  the  configuration  controller.  This  job  is 
particularly  important  in  the  initial  testing  stages  as  a 
particular  CCIU  complex  is  implemented  and  experience  is  gained  in 
its  performance. 

It  is  emphasized  that  a  configuration  controller  has  special 
privileges  recognized  by  the  CCIU  when 'he  'logs  on'.  A  user  cannot 
make  changes  in  the  CCIU  internal  state. 

.1.3  Developers 

A  third  access  class  is  developers.  This  is  the  group  thet 
develops  software  to  be  used  on  the  CCIU  and  is  able  to  create  new 
functions  or  modify  existing  ones.  Field  commanders  will  not 
develop  CCIU  Software.  All  developers  will  be  in  Post  Deployment 
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Support  Commands  and  have  access  to  special  CCHTs  or  components  as 
needed . 

It  is  a  consequence  of  the  above  situation  that  field  CCIU 
installations  will  not  need  to  possess  such  software  as  Ads 
compilers,  linkers,  and  the  other  environmental  support  software 
necessary  for  program  development. 

6.2  Peer  Interface 

The  user  interface  to  the  CCIU  will  be  through  the  User  Interface 
Directive  Language  (UIDL),  which  is  a  problem-oriented  executive 
language.  It  will  delineate  specific  functions  that  can  be  per¬ 
formed  by  the  system.  For  example,  a  possible  command  could  be: 
"DISPLAY  HISTOGRAM  OF  DEADLIHED  VEHICLES  BY  DEADLINE-CAUSE".  This 
type  of  executive  language  is  in  contrast  to  a  language  which  is 
procedural  and  would  require  the  user  to  make  separate  requests  to 
query  the  database  to  find  the  appropriate  vehicles,  construct  a 
histogram,  and  then  activate  a  display  of  the  histogram.  A  series 
of  commands  used  sequentially  to  accomplish  a  higher  level 
function,  not  directly  implemented,  can  be  stored  and  then  recalled 
by  name. 

The  user  language  must  be  designed  so  it  can  be  used  easily  by 
inexperienced  users.  This  can  be  accomplished  by  including  several 
features  described  below.  (1)  On-line  commands  will  be  provided 
which  inform  the  user  of  the  available  commands  in  the  system.  (2) 
While  executing  a  given  command  the  CCIU  will  provide,  if 
requested,  additional  information  as  to  what  alternatives  are 
available  when  user  input  is  needed.  (3)  Automatic  recognition  of 
commands  when  they  are  distinguishable  from  other  commands,  al¬ 
though  the  complete  command  has  not  been  input,  will  be  provided. 
(4)  The  user  can  set  a  level  of  expertise  into  the  system  and  the 
amount  of  information  he  receives  for  prompting  will  be  adjusted 
accordingly.  .(It  is  very  frustrating  to  look  up  additional 
information  off-line  and  equally  frustrating  to  watch  a  great  deal 
of  useless  prompting  when  the  user  is  an  expert).  This  type  of 
user  interaction  was  pioneered  in  the  TENEX  operating  system 
developed  by  Bolt,  Beranek,  and  Newman. 

The  user  interface  also  provides  a  great  deal  of  control  over 
access  to  the  system.  When  the  user  "logs  on"  to  the  CCIU  his 
identity  is  known.  The  logging  process  can  authenticate  the  user, 
and  connect  him  directly  to  a  command  processor  specifically 
designed  for  his  level  of  access  and  with  capabilities  for  the 
appropriate  data  and  command  objects.  This  is  possible  because  the 
user  is  completely  isolated  from  direct  interaction  at  the  machine 
level  and  has  only  the  capabilities  granted  by  the  log  in  process. 
A  similar  aceess  control  was  pioneered  by  MIT  and  is  used  in  their 
MULTI CS  system. 
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Development  of  CCIU  software  ie  only  poeeible  by  individuals  carry¬ 
ing  the  special  privileges  of  the  developer  and  is  not  done  in  the 
field  environment. 
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ACCS 

Ada 

Applications  User 
Array  C^ 

Associativa  Mass  Storage 
System 

BAA  V 

Backbone  Network 

Backup 

Behavioral  Template 

BER 

Bit  Error  Rate 

CACDA 

CAL 

Capabilities 

Capabilities  Mechanist 


Army  Command  and  Control  System 

Defense  Department  computer  language. 

A  aon-privlleged  user  who  has  access  only  to 
appropriate  user  applications. 

Army  Command,  Control  and  Communication 

A  mass  storage  system  in  which  data  can  be 
accessed  by  content  rather  than  address,  e.g., 
LIST  NAMES  OF  ALL  RED-HAIRED  MEN,  rather  than 
LIST  LOCATIONS  165FA,  165FB,  etc.  (locations 
pointing  to  names  of  red-haired  men) . 

Battlefield  Automation  Appraisal  Five 

Comprises  the  three  higher  layers  of  the  CCIU 
network. 

Replication  of  the  user  functions  at  several 
CCIU  nodes  and  use  of  redundant  communication 
links  to  guarantee  survivability. 

The  hardware,  software,  communications 
configuration  that  the  CCIU  attempts  to 
maintain  [SAC-Doc]  (See  Current  Configuration). 

See  Bit  Error  Rate. 

A  ratio  describing  the  transmission  quality  of 
a  channel. 

The  U.S.  Army  Combined  Arms  Center. 

See  CCIU  Architectural  Level. 

Capabilities  are  system-wide  names  for  objects 
(e.g.,  I/O  devices,  memory  pages,  data  types, 
messages).  A  process  has  access  to  an  object 
only  if  it  possesses  a  capability  for  that 
object. 

Allows  cooperating  user  functions  to  share  dat 
objects,  each  with  a  capability  associated  wit 
it. 


Capability 


Each  shared  object  has  a  capability  associated 
with  it;  a  capability  is  permission  to  use  that 
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CCIU 


Command  and  Control  Information  Utility 


CCIU  Architectural  Levels 


CCP 


CCS2 

CECOM 

CENSEI 


Channel 


CNP 


The  architecture  of  the  CCIU  is  structured  in 
three  levels  called  the  CCIU  Architectural 
Levels.  They  are  the  Command  Slice  Functional 
User  Level,  the  Control  Level,  and  the 
Processor  Element  level. 

Cellular  Command  Post  -  a  DPM.  A  collection  of 
processing  elements  that  together  perform  the 
information  processing  functions  of  a  command 
post. 

Command  and  Control  of  Subordinate  Systems  -  a 
DPM. 

U.  S.  Army  Communications  and  Electronic 
Command 

Center  for  System  Engineering  and  Integration— 
a  component  of  CECOM. 

A  path  along  which  signals  carrying  data  can  be 
sent.  The  term  Implies  one-way  communication, 
while  "circuit"  implies  two-way  communications 
[DA VI  79 J. 

See  Contract  Net  Protocol 


Command  File  A  file  containing  a  sequence  of  directives, 

either  in  the  User  Interface  Directive  language 
or  a  procedural  language  that  causes  execution 
of  a  sequence  of  processes. 

Command  Slice  A  level  in  the  chain  of  command,  e.g.,  Corps 

Level  — >  Corps  Slice. 

Command  Slice  Functional  User  The  key  member  of  the  basic  user  population  for 

which  CCIU  is  designed.  Generally  corresponds 
to  a  functional  cluster  at  a  particular  command 
slice. 

Command  Post  Network  The  level  of  the  CCIU  communication  network 

that  interconnects  the  processor  elements  of  a 
CCP. 

Communications  Protocol  A  strict  procedure  required  eo  initiate  and 

maintain  communications.  Protocols  say  exist 
at  many  levels  in  one  network  such  as  link-by- 
llnk,  end-to-end,  and  subscrlber-to-s witch. 


GLOSSARY 


Concurrency  Control  Management  of  parallel  proceealng  to  maximize 

parallellen  while  maintaining  proceea 
synchronisation. 

Configuration  Controller  A  specially-privileged  user  who  has  access  to 

User  Interface  Directives  that  modify  CCIU 
configuration  and  control. 

Configuration  Tables  CCIU  actual  configuration  stored  in  the  current 

configuration  tables;  maintained  by  the  system 
monitor. 

CONOPS  Continuity  of  Operations 

Consistency  A  database  may  ba  viewed  as  a  finite  set  of 

objects  that  are  aeelgned  valuae.  The  set  of 
values  taken  by  all  objects  is  called  a  state 
of  the  database. 

Associated  with  the  database  is  a  set  of 
assertions  about  database  objects  and 
relations  between  database  objects  called 
consistency  constraints. 

The  state  of  a  database  is  consistent  if  the 
values  taken  by  all  objects  constituting  the 
database  satisfy  the  consistency  constraints. 
[LEU]. 

Context  Switching  Term  applied  to  operating  system  activity  of 

allocating  the  Central  Processor  Unit  (CPU)  of 
a  computer  to  one  process  that  is  ready  to 
execute  and  at  the  same  time  moving  the  process 
that  formerly  had  the  CPU  to  some  fora  of 
waiting  or  killed  state. 

Contingency  Handler  An  OS  routine  which  oversees  actions  taken  to 

ensure  or  increese  survivability  after  a 
failure. 

Contract  Het  Protocol  A  protocol  for  migrating  the  responsibility  for 

executing  a  process  that  preserves  a  high 
degree  of  autonomy  among  processors  [SAC-Doc], 
[SMIT  79]. 

Control  Element  Coordinates  technical  activities  of  Subordinate 

Systems  included  in  the  functional  element; 
provides  command/ staf f  type  information  to 
other  control  elements  or  accepts  such 
information  from  them. 
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Control  Level 
Control-VIP 

Correctness 

Correctness  Prover 

Current  Configuration 

CPU 

CSFU  Level 
CSFU-VIP 

Database 

Database  Management  Spates 

Database  Manager 
Database  Model 


A  CCID  Architectural  Level. 

Virtual  Information  Processor  that  implements 
the  Control  Level  of  the  CCIU  Architecture 
[SAC-DOC]. 

A  program  nay  be  represented  as  a  set  of 
logical  assertions  or  a  theorem.  If  the 
theorem  (or  set  of  assertions)  can  be  proved  by 
formal  logic,  the  program  is  said  to  be 
correct. 

An  automated  capability  to  prove  program 
correctness.  See  Correctness. 

The  hardware,  software,  communications  config¬ 
uration  that  exists  In  the  CCIU  at  any  time. 

May  be  different  from  the  Behavioral  Template 
as  a  result  of  environmental  causes. 

Command  Post  Network. 

Command  Slice  Functional  User  Level  of  CCIU. 

Virtual  Information  Proce8aor  that  supports  a 
Command  Slice  Functional  user. 

A  collection  of  interrelated  data  stored 
together  to  serve  one  or  more  applications 
[MARX  77]. 

The  collection  of  software  required  for  using  a 
database  [MART  77]. 

See  Database  Management  System. 

A  generalised  logical  framework  for  describing 
the  relationships  among  data  objects.  There 
are  currently  three  widely  accepted  data 
models:  The  Network  Model,  the  Hierarchical 
Model,  and  the  Relational  Model.  Adapted  from 
[CARD  79]. 

These  three  models  employ  low-level  record 
constructs.  Semantic  Database 
Models  are  database  models  that  present  to  the 
user  a  view  of  his  database  environment  that  is 
expressed  in  terms  of  high-level  constructs. 
These  constructs  are  more  semantically 
expressive  of  the  user's  environment. 
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Deadlock. 

Directed  Protocol 

Distributed  Processing 

Distributed  Processing 

DMS 

DPK 

Echelon  Network 
Echo  Algorithm 

Ethernet 

Functional  Cluster 

I/O  Device  Driver 

ISO-OS I  Open  Systems 
Interconnection  Model 


A  deadlock  is  said  to  occur  when  a  process  can 
never  be  granted  all  the  resources  it  needs 
to  reach  coapletlon  (adapted  fron  [LELA] ) . 

A  protocol  for  migrating  the  responsibility  for 
executing  a  process*  The  processor  to  which 
the  process  is  directed  has  only  limited  choice 
to  refuse  the  assignment. 

Model  DPM:  One  of  a  set  of  models  which  characterize 
the  back  up  and  communications  requirements  for 
the  CENSEI  distributed  processing  development 
program. 

System  A  computing  system  In  which  processing  is 
distributed  among  two  or  more  processors. 

"True"  distributed  processing  is  usually 
associated  in  the  literature  with  “control 
decentralization”  (see  e.g,  [LELA  79]). 

See  Database  Management  System. 

See  Distributed  Processing  Model. 

Links  together  unit  networks  at  the  same 
echelon  level. 

One  of  a  class  of  decentralized  algorithms  for 
determining  arbitrary  characteristics  of  a 
network  in  a  manner  that  avoids  exponential 
growth  of  associated  message  overhead. 

A  type  of  local  network  protocol  first 
developed  by  the  Xerox  Corporation. 

Refers  to  clusters  of  command  and  control 
functions  that  are  characterized  by  a  high 
level  of  Interaction  within  the  duster  but  a 
lower  level  of  Interaction  between  dusters. 

There  are  five  functional  dusters:  Maneuver, 
Fire  Support,  Intelligence  and  Electronic  War¬ 
fare,  Air  Defense  Artillery,  Combat  Services 
Support. 

Procsssor  software  dedicated  to  servicing 
specific  I/O  devices. 

The  Open  Systems  Interconnection  Model.  An 
International  Standard  Model  for  the  structure 
of  the  communications  Interface  In  a  network 
PE  [ZIMM  80]. 
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Kernel 

L as 

Locking 

Logical  Massage 

Loosely  Coupled  Systen 

Mesa  Storage 

Mlg  ration 

Non-Procedural  Language 
Operating  Systen 

Operating  Systen  Kernel 

OFF AC/ COHOPS 


A  layer  o£  the  PEOS;  implements  the  basic 
systen  primitives. 

Local  Nana  Space 

A  mechanism  that  limits  access  to  a  data  object 
to  only  one  transaction  as  long  as  necessary  to 
preserve  consistency  [LZLA] . 

Message  in  the  format  recognized  by  a  process 
(see  Physical  Message) . 

The  rate  of  interaction  BETWEEN  processors 
making  up  the  system  is  small  compared  to  the 
rate  of  interaction  WITHIN  processors  [SIMO 
80]. 

Very  large  (begabyte)  secondary  storage, 
usually  consisting  of  a  hierarchy  of  storage 
madia  In  which  data  Is  staged  from  slow-access, 
low-cost  media  to  rapid-access,  higher-cost 
media. 


As  used  here,  refers  to  the  capability  to 
designate  any  appropriate  processor  to  execute 
a  process.  It  may  require  moving  code  to  the 
designated  processor. 

Language  that  specifies  WHAT  rather  than  HOW. 
(See  Procedural  Language.) 

Those  program  modules  within  a  computer  systen 
that  govern  the  control  of  equipment  resources 
such  as  processors,  main  storage,  I/O  devices, 
and  files. 

These  modules  resolve  conflicts,  attempt  to 
optimize  performance,  and  simplify  the 
effective  use  of  the  system  [MADN  74] . 

The  operating  system  nucleus.  The  kernel 
provides  a  small  number  of  primitive  operations 
callable  from  user  processes.  It  implements  a 
number  of  abstract  objects  and  valid  operations 
on  each  object. 

It  Is  the  only  module  in  the  system  empowered 
to  execute  hardware  privileged  instructions 
[POPE  79]. 

Operational  Facility;  Continuity  of  Operations 
-  a  DFM 


GLOSSARY 


OS 

Ownership 

Packet  Protocol 

PCB 

PUSS  Command 

PE 

PEOS 

Physical  Message 

Post  Deployment 
Software  Support 

Predicate 

Predication 

Presentation  Control 

Privileged  Functions 

Privileged  Machine 
Instructions 

Privileged  User 

Procedure 


See  Operating  System. 

In  the  SAC-Doc,  the  authority  of  a  field 
commander  to  move  items  that  are  CCIU  resources 
and  to  elect  whether  or  not  to  put  them  at  the 
disposal  of  the  CCIU. 

A  block  of  data  handled  by  a  network  in  a  well- 
defined  format  including  a  header  and  having  a 
maximum  size  of  data  field.  Consequently,  a 
message  may  have  to  be  carried  as  several 
packets  [DA VI  79]. 

Process-Control-Block 

Military  commands  that  have  the  responsibility 
for  Post  Development  Software  Support* 

See  Processor  Element. 

Processor  Element  Operating  System 

Message  in  the  format  recognized  by  the 
carrier.  (See  Logical  Message) 

See  PDSS  command. 


That  which  is  asserted  about  a  subject. 

A  logical  assertion. 

Process  A  process  that  initiates  and  maintains  a 

presentation.  Presentation  is  the  ISO-ANSI 
term  for  the  data  translation  activity  that 
takas  place  between  heterogeneous  objects, 
e.g.,  that  necessary  to  maintain  a  display. 

Functions  to  which  access  is  limited  to 
authorized  users. 

Instructions  which  can  only  be  executed  when 
the  machine  is  in  a  special  mode  utilized  only 
by  the  OS. 

One  capable  of  modifying  CCIU  software  in  ways 
over  which  the  CCIU  has  no  control. 

A  body  of  code,  linked  and  ready  for  execution 


GLOSSARY 


Process 

Process  Control  Block 

Process  State 

Process  Synchronization 


Processor  Element 

Processor  Element  Level 
Protocols 

Query 


An  Instance  of  a  procedure  that  Is  active  on  a 
PE.  Processes  accomplish  the  computing  on  a 
system. 

An  Information  storage  block,  created  for  every 
process  at  the  time  the  process  Is  created, 
chat  contains  Information  needed  for  the 
process  to  execute,  e.g.,  process  priority, 
capabilities,  data,  etc. 

The  status  of  s  process  relative  to  its 
eligibility  to  gain  access  to  the  CPU 
[SAC-DOC].  There  are  five  states:  Active, 
Waiting,  Blocked,  Submitted,  Inactive  or 
Killed. 

Multi-process  systems  involve  atomic 
operations.  An  operation  Is  a  set  of  actions 
performed  by  one  or  more  processes  at  the 
Instigation  of  another  process. 

“Atomic”  means  either  all  actions  are  completed 
and  a  consistent  system  state  is  achieved,  or 
no  actions  are  completed  and  the  current  state 
Is  unchanged. 

Synchronization  is  the  process  of  enforcing 
atomicity  despite  conflicts  among  concurrent 
operations,  unreliable  communications,  variable 
communications  delays,  variable  numbers  of 
processes  and  processors  [JENS  80] . 

A  collection  of  one  or  several  processing  units 
under  control  of  a  SINGLE  operating  system.  It 
Is  the  fundamental  computer  element  of  the 

ccxu. 

A  CCIU  Architectural  Level. 

Provide  services  such  as  message  sequencing, 
priorities,  error  and  flow  control.  Also 
establish  standard  data  elements  and 
communications  conventions  [MCQD  78,  TANE  81]. 

A  type  of  database  transaction  in  which  data 
is  retrieved  from  the  database. 

A  flat  fils  or  table.  A  relation  is  the  basic 
data  object  of  the  relational  data  model.  Rows 
In  the  table  are  called  “tuples.”  Columns  are 
called  "domains.” 


Relation 


GLOSSARY 


Relational  Modal 
Reliable  Network 

Resource  Manager 

Roll-Back 

Roll-Forward 

SAC-Doc 

Schema 

Semantic  Database  Model 
Semantic  Dictionary 

Slice 

SS 

Subschema 

Survivability 


The  contents  of  a  row-column  intersection  is 
called  an  attribute  value.  The  term  "flat 
file"  refers  to  the  requirement  that  an 
attribute  be  atomic,  l.e.,  not  a  repeating 
group;  (adapted  from  [CARD  79]). 

A  set-oriented  data  model.  See  Database  Model 

Communications  system  that  delivers  messages  in 
sequence  and  accounts  for  lost  and  duplicated 

messages. 

Module  that  manages  allocation  «f  memory,  disk 
space,  processor  usage  and  other  FE  resources. 

The  process  during  reezecutlon  of  a  failed 
transaction,  of  restoring  the  database  to  its 
(consistent)  state  before  the  transaction 
started  ( see  Roll-Forward) . 

The  process  of  reexecutlng  a  failed 
transaction. 

System  Architectural  Concepts  Document— short 
title  for  Preliminary  System  Architectural 
Concepts:  Army  Battlefield  Command  and  Control 
Information  Utility  (CCIU). 

A  map  of  the  overall  logical  structure  of  a 
database  [MART  77]. 

See  Database  Model 

A  description  of  the  logical  structure  of  a 
database  including  all  logical  views  and 
available  data  transactions. 

See  Command  Slice 

Subordinate  System.  A  processor  element  of  a 
CCP.  (Compare  with  Control  Element.) 

A  map  of  the  logical  structure  of  that  subaet 
of  the  schema  used  by  a  single  application  or 
group  of  applications  [MART  77]. 

Probability  that  a  system  can  continue  to 
perform  its  intended  function  at  an  acceptable 
level  in  a  hostile  environment.  Specifically, 
the  ecru's  ability  to  continue  operation  even 
with  loss  of  some  of  its  communication  links 
and  processor  elements. 
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System  Integrity 


Includes  all  internal  aspects  of  the  CCIO 
concerned  with  proper  operation. 


TAM 


See  Task  Assignment  Manager 


Task  Assignment  Manager 

Task  Force 

Task  Manager 

TCS 

TCT 

TM 

TEA  DOC 
Transaction 

Transparent 


A  Task  Force  that  tries  to  maintain  global 
knowledge  of  the  CCIU  and  oversees  the  locating 
of  processes  and  migration  of  processes. 

A  collection  of  cooperating  processes,  perhaps 
coordinated  by  an  executive  process. 

Controls  task  assignment  in  an  individual  PE. 

Military  Tactical  Computer  System 

Military  Tactical  Computer  Terminal 

See  Task  Manager 

Training  and  Doctrine  Command 

Any  activity  that  Involves  retrieving,  adding 
to,  changing,  or  deleting  database  objects. 

See  Trans parent/ Virtual 


Transparent/ Virtual  In  the  sense  used  in  the  SAC-Doc,  transparent 

and  virtual  are  related.  A  virtual  object  is 
one  that  appears  to  the  user  to  be  present,  but 
is  not.  A  transparent  object  appears  to  the 
user  NOT  to  be  present,  but  is. 

A  CONTROL -VIP  is  a  virtual  object.  A  disk  I/O 
processor  is  a  transparent  object. 

UIDL  See  User  Input  Directive  Language 

Unit  Network  Links  together  the  CPN' s  belonging  to  the  same 

Army  unit. 

User  A  nou-privileged  user  of  the  CCIU. 

User  Input  Directive  Language  High-level  language  used  by  users  to  interface 

with  CSFU-VIP. 

VIP  See  Virtual  Information  Processor 

Virtual  See  Transparent/Virtual 
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Virtual  Circuit  A  system  In  which  messages  are  delivered  to  a 

specified  destination  over  many  different 
routes  that  may  be  tranaparent  to  the  user. 
The  link  appears  to  the  user  as  a  direct 
connection  between  the  sender  and  receiver. 

Virtual  Information  Processor  A  virtual  machine  (i.e.,  a  software  processor) 

optimized  to  meet  an  interrelated  set  of 
requirements. 
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